System, method and database for processing transactions

ABSTRACT

A check transaction processing system using a customer&#39;s checking account identification number as a unique customer identification code (“check ID”) comprising a transaction processor for processing check transactions for a store, and for storing a customer database, including customer records, for that store; each customer record being uniquely identified by the customer&#39;s check ID, and including selected customer information; said customer information including check verification status information such that a customer is assigned a check verification status value of positive, negative, or caution.

TECHNICAL FIELD OF THE INVENTION

This invention relates to transaction processing and analysis systems,including check verification systems, and more particularly, to a methodand system for processing and developing a local customer database ofcustomer information, such as check verification status and transactionfrequency and dollar volume over specified intervals, that can be usedfor check verification, marketing and other customer relations purposes.

BACKGROUND OF THE INVENTION

Retail and other business establishments that serve a large number ofcustomers generally have a problem obtaining transactional informationabout their customers, such as for identifying new customers anddetermining transactional patterns for repeat customers (such astransactional frequency and dollar volume).

For those stores that experience a high volume of check transactions, animmediate customer information problem is determining whether toauthorize a check transaction in the typical situation where the salesclerk does not personally know the purchaser. Beyond this immediateproblem of check verification, these stores have a broader need forgathering transactional information that could be used in developingcustomer profiles useful in targeting advertising, marketing andpromotions.

For example, a typical grocery store does a high transactional volumewith checks comprising a significant percentage of the totaltransactions (typically as much as 85%). These businesses strive formaximum efficiency in completing transactions at the checkout counter,which results in a minimum of contact between the customer and the salesclerk. In this sales environment, neither clerks nor store managerstypically develop any significant personal relationship with anindividual customer.

Since check transactions account for such a significant percentage of agrocery store's business, these stores naturally make an effort tominimize the number of bad checks that will be returned. Typically, thestore will require an additional piece of identification, such as adriver's license and/or a major credit card. However, this requirementfor additional identification reduces the efficiency of the checkoutprocess, and inconveniences the significant majority of checktransaction customers who do not write bad checks—typically, a grocerystore's bad check experience will be approximately 2% of its checktransactions.

Thus, check verification presents a store with problems in customerrelations and risk management. A store naturally seeks to improvecustomer relations with the great majority of customers who do notpresent check transaction problems by efficiently and quicklyauthorizing check transactions. However, the store must guard againstthe financial risks from customers who do write bad checks, either aspart of a concerted bad check scheme or as a result of less larcenousconduct that may range from simple bookkeeping mistakes to overlyaggressive check floating. In the former case, bad check risk is greatlydependent upon abnormal check transaction activity over a giveninterval. In the latter cases, the bad check risk is greatly dependentupon check transaction history (total check transaction frequency anddollar volume at a store).

The check transaction risk management problem has two principalaspects—the risk that a person will write a bad check and the risk thata bad check cannot be recovered. Again, both of these risk factors aregreatly dependent upon a customer's historical check transactionactivity. As the total number of check transactions by a customer at aparticular store increases, both the risk that the customer will write abad check decreases, and more significantly, the risk that store willnot be able to recover on a bad check decreases.

For example, a customer with fewer than 200-300 check transactions at astore presents a relatively high risk in terms of recovery on a badcheck, while a customer with more than 600-700 check transactionspresents a minimal risk. Thus, a store practicing risk management shouldput substantially more restrictions in terms of check transactionfrequency and total dollar volume over given intervals in the formercase than in the latter.

These risk management problems are multiplied in the case of multiplestore businesses, particularly in the case of concerted bad checkcashing schemes. In that case, the typical pattern is to move from storeto store within a relatively short period of time.

Beyond these check verification and risk management problems, grocerystores have a broader problem in accumulating customer informationbecause of the emphasis on minimizing the amount of time required for asales transaction, and the attendant impersonality of the customerrelationship. Thus, it is extremely difficult to develop any meaningfulcustomer profiles, or to identify customer groups such as regularcustomers and new customers who might become regular customers. If astore could accumulate more detailed customer information, customerprofiles could be developed and used for targeted advertising, marketingand promotional programs.

Accordingly, a need exists for a transaction processing system forindividual stores (in both single and multiple store environments) thatfacilitates check transactions by improving the efficiency of the checkverification process, and that maintains a local customer databasecontaining transactional information about the store's customers usefulfor check verification risk management, and for other customer relationspurposes such as identifying new customers and profiling regularcustomers.

Check or credit verification systems are commonly used today to verifycheck/credit transactions. Typically, these systems include anegative-status database of individuals for whom check or credittransactions will not be authorized (for example, because of anoutstanding bad check). In response to requests for check transactionverification, these systems indicate that the customer's status iseither positive (transaction authorized) or negative (transaction notauthorized).

U.S. Pats. RE. 30,579, RE. 30,580, and RE. 30,821 (Goldman) disclose asystem for commercial retail establishments in which customer recordsare identified by arbitrary identification information such as adriver's license number and contain some customer status andtransactional data (such as bad check history and frequency of checkingtransactions in a given period). For each check transaction, the clerkenters into a transaction terminal the customer's arbitraryidentification. Such systems have not been commercially practical,because store customers dislike having to identify themselves,particularly when they have been long-time customers of the store.

In the systems disclosed by Goldman, if the customer database contains acorresponding customer record, a customer status indication (positive ornegative) is returned to the clerk. If the customer database does notcontain a corresponding customer record, the system creates a newrecord, and indicates first-time/interim status for the customer. Thedatabase is regularly updated by changing customer status to reflectcheck transaction experience or the sufficient passage of time for checkclearance to allow transfers from first-time/interim status to positivestatus. Such first-time/interim status as taught by Goldman is dangerousfor the store owner, as a customer can gain access to a positiveindication level, thus enabling the cashing of many checks in a shorttime period, by the clearing of only a single check.

Existing check transaction processing systems are disadvantageous forhigh-volume check transaction operations. In particular, the Goldmanpatents do not disclose a practical system for businesses to efficientlyverify check transactions, while developing a localized customerdatabase for each store that may be used by the store to developcustomer profiles useful for marketing and other customer relationspurposes. The Goldman system, and others, are based on using some formof identification with the customer's check, a procedure that both slowsthe check transaction process and inconveniences the large majority ofcustomers who will not present a bad check. Moreover, such systems asdisclosed in the Goldman patent do not enable sufficient control over acustomer's check transaction frequency and dollar volume, and thussubject the store owner to substantial financial risk.

Many such systems require connecting a point-of-sale terminal throughtelephone lines to a remote transaction processing system, therebyincreasing not only the cost of operating the systems, but alsoincreasing the time for providing check verification. Also, existingsystems typically do not focus on maintaining a local customer databaseuseful not only for check transaction processing, but also foridentifying new customers and developing customer profiles for regularcustomers.

SUMMARY OF THE INVENTION

Important aspects of the present invention are to facilitate checktransactions by reducing the requirements for customer identification,to enable a store to adopt a risk management approach to checkverification based on a customer's transactional history (frequency anddollar volume over specified intervals), and to improve a store'smarketing and other customer relations programs by collectingtransactional data for that store, both current and historical, that canbe used to identify new customer's and develop customer profiles.

More specifically, this invention is a check transaction processingsystem that uses a customer's checking account number as a uniquecustomer identification number. Thus, the system does not requiretime-consuming checking of additional customer identification, but onlyrequires the speedy entry of the customer's checking account number. Thesystem operates at an individual store, and maintains at that store alocal customer database of customer records, each identified by thecorresponding customer check identification number. The customer recordsalso include customer information, such as check verification data (suchas verification status) as well as other selected transactional data(such as transaction frequency and dollar volume), the verification andtransaction data being regularly updated with new data (such as duringcheck transaction verification).

The system includes one or more transaction terminals, coupled to atransaction processor that stores the customer database. A transactionterminal is used to transmit a customer information request (such as forcheck transaction verification), which includes a customer's checkidentification number, from the point-of-sale (POS) to the transactionprocessor.

The transaction processor processes the customer information request,using the check identification number to search the customer databaseand retrieve the corresponding customer record, if any. Based on thecustomer information in the customer record, or the lack of a customerrecord, the transaction processor returns an appropriate response (suchas check verification status) to the transaction terminal.

Thus, the method of this invention for check transaction processinginvolves: (a) identifying a customer by the customer's unique check ID;(b) developing and maintaining for a store a local customer database ofcustomer records, each identified by the corresponding customer checkidentification number, and each including customer information (such asverification status and transactional data); (c) generating a customerinformation request; (d) processing the request using the customer checkidentification number to access the corresponding customer record, ifany; (e) returning an appropriate customer information response based onthe customer information in the customer record; and (f) updating thecustomer database regularly to reflect new customer information.

More specific aspects of the preferred embodiment of the invention arethe following.

The transaction terminals and the transaction processor form a tokenring data communication network. Each transaction terminal includes (a)a keypad for entering check identification numbers, function codes andappropriate transaction data, which form customer information requests,and (b) a display for displaying the requests and the returnedresponses.

The customer records in the customer database include an assigned checkverification status, such as POSITIVE (transaction authorized), NEGATIVE(transaction not authorized) or CAUTION (transaction should bescrutinized or subject to certain conditions). The first time a customerattempts a check transaction at a store (i.e., a search of the customerdatabase pursuant to a check verification request indicates no existingcustomer record), a new customer record with a CAUTION status iscreated, and a CAUTION response is returned to the transaction terminal.The customer remains in the CAUTION status for a period of timesufficient for this initial check to clear or be returned. If thisCAUTION/POSITIVE interval passes, the system automatically updatesstatus to POSITIVE; if the check is returned, customer status is updatedby inputting a NEGATIVE status.

In addition to check verification status data, the local customerdatabase includes transactional data such as transaction frequency anddollar volume over specified intervals. This transactional data can beused to place conditions risk management on check transactionverification over and above verification status. For example, in thecase of a customer with either CAUTION or POSITIVE status, if a checktransaction exceeds certain specified transaction limits frequencyand/or dollar amount over a specified interval (such as day, week ortotal), a CALL MANAGER response is returned in response to a checkverification request, regardless of customer status.

Moreover, because the check transactional data is generated andmaintained locally, it provides significant information about thestore's customers over and above the information necessary for checkverification risk management. New customers are readily identified, andfrequency and dollar volume information may be used to establishcustomer profiles and to target advertising, marketing and promotionalprograms, and for other customer relations purposes.

In the case of a multiple store business, each store has a local checktransaction processing system, with one of the systems being designateda host site and the rest being designated remote sites. At selectedintervals, each remote system transmits to the host selected customerinformation from its local customer database (such as customer recordsfor those customers with CAUTION and NEGATIVE status includingtransactional data), which is used to update the host customer databaseto include this global customer information. The host, in turn,transmits that global customer information to the other remote systems.

Check transaction processing is implemented by a multi-tasking programexecuting in the transaction processor. The program includes: (a) aterminal manager task that implements network data communication for thetransaction terminals, communicating customer information requests andresponses; (b) a Data Manager Task that controls the database operationsnecessary to respond to customer information requests and to update thecustomer information in the database; and (c) an Event Manager Task thatimplements system activities such as backup and database purge, and inthe case of multiple-store systems, implements host/remotecommunications activities to transfer selected customer informationamong the stores for updating each store's local customer database withthe selected global customer information.

Important features and advantages of this invention are the following.The check transaction processing system uses as a unique customeridentification number the customer's check identification number,avoiding the requirement for additional identification and the attendantdelay in completing the check transaction.

The system develops and maintains a local customer database, allowingthe store to accumulate customer information relevant to the store'scustomers over and above that information necessary for checkverification. The system provides for the selection of procedures andcriteria for database management and check verification, allowing thestore owner/manager considerable flexibility in developing and using thecustomer information in the store's customer database.

For check verification, the system uses three primary statuslevels—POSITIVE, NEGATIVE and CAUTION—allowing the store to identifythose customers with a bad check outstanding, and to identify newcustomers and establish selected interim risk management procedures forgranting those customers check transaction privileges. In addition tocheck verification status, the system collects and accumulates selectedadditional transactional data, including frequency and dollar amountsover specified intervals (such as day/week/total) and other historicalinformation, allowing the store to adopt risk management approach tocheck verification tailored to the store's particular customer andfinancial situation by conditioning check authorization on meetingcertain selected transactional limits regardless of customer status (theCALL MANAGER response), and allowing the store to develop customerprofiles and to target advertising, marketing and promotions, andotherwise improve customer relations.

For multiple-store businesses, the system can use automatic host/remotetransfer of selected customer information to upgrade the local customerdatabase at each store with global customer information (such as thosecustomers with CAUTION and NEGATIVE check verification status), therebymaximizing protection against bad checks while maintaining the localcharacter of the store's customer database.

The check transaction processing system is implemented by amulti-tasking program, and uses local area network data communicationamong the transaction terminals and the transaction processor, allowingefficient operation of the system at each individual store.

Other objects, features and advantages of this invention will beapparent from the drawings and the following detailed description of thepreferred embodiment, and the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the check transaction processing system of this invention,including a multiple store remote/host configuration.

FIG. 2A shows a transaction terminal, including the display and thekeypad.

FIG. 2B shows schematic circuit detail for the transaction terminal.

FIG. 3 functionally diagrams the check transaction processing system.

FIG. 4 diagrams the verification function.

FIG. 5 diagrams the local status update function for both Add and DeleteNEGATIVE status.

FIGS. 6A and 6B diagram the global update function for, respectively,the host and a remote system.

FIG. 7 shows the program tasks that form the check transactionprocessing program.

FIG. 8 is a program flow diagram of the System Kernel that provides taskswitching and intertask communication for the other program tasks.

FIG. 9A is a program flow diagram of the Data Manager Task.

FIGS. 9B-9H are program flow diagrams of selected function executionroutines in the Data Manager Task, respectively, verify roll, addNEGATIVE, delete NEGATIVE, host global update (negative status records),host global update (customer records), and remote global update(customer records).

FIGS. 10A and 10B are program flow diagrams of, respectively, theTerminal Manager Task network polling function, and the terminal requestsubtask.

FIGS. 11A and 11B are program flow diagrams of, respectively, the EventManager Task, and the event subtask.

FIG. 12 is a program flow diagram of the Modem Manager Task.

DESCRIPTION OF THE PREFERRED EMBODIMENT

The check transaction processing system of the present invention enablesa store with a significant volume of check transactions to accumulateand process transactional customer information for two main purposes:check verification and customer profiles. The system operates at thestore using a local database of customer information useful in thatstore's business.

A customer's bank checking account number provides a uniqueidentification for that customer—using this check ID, a customer recordis created and included in the local customer database. The customerrecord includes an assigned customer verification status, as well asselected transactional data. Customer status designations includePOSITIVE, NEGATIVE and CAUTION, while transactional data includestransaction frequency and dollar volume over given intervals (such asDay/Week/Total or DWT). Selected transactional (CALL MANAGER) limits areassigned to both CAUTION and POSITIVE status. This customer information(customer status and transactional data) in the customer database iscontinuously updated (a) on a local basis through either processingcheck verification requests, or inputting customer status, and (b) inthe case of a multiple store business, on a global basis throughinter-store transfers of selected customer information (such as CAUTIONand NEGATIVE status information).

The description of the preferred embodiment of the check transactionprocessing system is organized as follows: 1.0 Hardware Description 1.1.System Overview 1.2. Data Communications Network 1.3. TransactionTerminal 1.4. Multiple-Store Configuration 1.5. Exemplary Components 2.0Functional Description 2.1. Database Structure 2.2. Function Codes 2.3.Verify/Query 2.4. Local StatusUpdate 2.5. Global Update 2.6. Purge 2.7.Event/Activity 2.8. Communications 2.9. System 2.10. Risk Management2.11. Customer Profiles 3.0 Program Description 3.1. General 3.2. SystemKernel 3.3. Data Manager Task 3.4. Terminal Manager Task 3.5. EventManager Task 3.6. Modem Manager Task 3.7. System/Screen Tasks 4.0Additional Embodiments 4.1. Hardware 4.2. Standard Multi-TaskingOperating System

1.0 CHECK TRANSACTION PROCESSING SYSTEM

The check transaction processing system is located at a store, andmaintains a local customer database for that store. For a multiple storebusiness, a local system is located at each store and global customerinformation transfers are used to supplement the essentially localcustomer database.

1.1. System Overview. As shown in FIG. 1, a check transaction processingsystem 110 located at a store includes a transaction processor 112coupled to a disk system 114 that stores the customer database used incheck transaction processing. Transaction processor 112 handles all fileI/O for accessing, managing and updating the customer database.

Transaction processor 112 is coupled through a network datacommunications interface 116 (including network communications ports andassociated drivers) and a network bus 118 to a plurality of transactionterminals 120. Transaction processor 112 is able to communicate withother check transaction processing systems through a telecommunicationsinterface 117 (including a modem).

Transaction terminals 120 are each located at a point-of-sale (such as agrocery store checkout stand). Transaction terminals 120 are used tocommunicate information to transaction processor 112 for checktransaction processing and customer database management. A transactionterminal transmits a request (including a function code identifying therequested function together with other request data) to the transactionprocessor, which processes the request and returns an appropriateresponse.

For example, in the case of check verification, a transaction terminalis used to transmit a verification request—the customer's check ID, theverification function code, and the dollar amount. The transactionprocessor processes the request, updates the customer database toreflect that transaction, and returns a customer verification statusresponse.

1.2. Data Communications Network. Data communications betweentransaction processor 112 and transaction terminals 120 is implementedusing a multi-drop token ring network. Network bus 118 connects thetransaction terminals to the transaction processor in a starconfiguration so that all data signals transmitted over the network arereceived at each node. Each transaction terminal 120 is assigned aunique terminal address to identify its data communications.

Transaction processor 112 implements a token-passing protocol bybroadcasting polling sequences (or cycles) in which tokens aresequentially addressed to the transaction terminals. For each poll, thetransaction processor sends to a terminal one of two tokens (which bothinclude the terminal address): POLL Token An invitation for the terminalto transmit data RXDATA Token Includes data requested by the terminal

In response to a POLL token, the transaction terminal transmits back oneof two answers: TXDATA Answer Includes data entered into the terminalNODATA Answer Indicates no data

During any given polling sequence, each transaction terminal is in oneof three polling states that control the polling operation: Poll Send aPOLL token Wait Do not send a token until requested data is availableData Send an RXDATA token that includes the requested data in theterminal's buffer

For example, in response to a POLL token, a transaction terminal maytransmit a TXDATA Answer containing a check verification request. Oncethe request is transmitted, the terminal is placed in the Wait stateuntil the verification response from the transaction processor isavailable. The response is placed in the terminal's buffer, and theterminal is placed in the Data state. The response is included in anRXDATA token sent to the terminal during the next polling sequence, andthe terminal is placed in the Poll state ready to receive a POLL tokenin the next polling sequence.

For the preferred embodiment, network communications interface 116provides 32 ports for up to 32 transaction terminals. The datacommunications network uses the RS485 line protocol, which specifiesdifferential signal lines SIG+ and SIG−, as well as +12V and groundlines. The network communications interface and the correspondinginterfaces for each transaction terminal use a differential line driverfor signal communication over network bus 118, which provides thenecessary 4-wire signal path.

1.3. Transaction Terminal. As shown in FIG. 2A, each transactionterminal 120 includes a keypad 122 and a display 124. Keypad 122 is a4×4 key matrix that includes specific keys for Function, Enter, Scroll,Clear and Back Space, as well as 0-9 and $. Display 124 is a liquidcrystal display capable of displaying two lines of up to twentycharacters each.

For example, to initiate a check verification request, keypad 122 isused to enter the customer's check ID and the amount of the check, alongwith the function code designating check verification. This request isdisplayed on display 124, and sent to transaction processor 112. Thecheck verification response, including the customer's verificationstatus (such as POSITIVE, NEGATIVE or CAUTION), returned by thetransaction processor is then displayed on display 124.

As shown in FIG. 2B, a transaction terminal 120 includes:

-   -   (a) A Z8 microprocessor 130;    -   (b) An associated address latch 132;    -   (c) An EPROM 134;    -   (d) An LCD (liquid crystal display) module 136; and    -   (e) A differential transceiver 138.        Address and data paths are provided by an Address/Data Bus and a        separate Address Bus.

The transaction terminal is coupled to the RS485 multi-drop network bus(118 in FIG. 1) through a 5-Pin DIN connector 140. The RS485 network busprovides signal lines SIG+ and SIG−, along with a +12 volt power lineand a ground line.

EPROM 134 provides program memory for microprocessor 130, while LCDmodule 136 constitutes data memory. That is, the LCD module functionallyinterfaces to the microprocessor as memory, providing an 80-characterdisplay data register that is treated by the microprocessor as datamemory.

EPROM 134 stores programs to control keypad 122, display 124 (i.e., LCDmodule 136) and network data communications. The keypad program includesconventional routines for decoding key-struck signals and receivingentered characters, as well as key-debouncing and N-key rollover. Thedisplay program includes conventional routines that write characters toand read characters from the display data register in LCD module 136. Tothat end, the display program provides mode control commands to LCDmodule 136 that control read/write operations, as well as operations forcursor positioning, backspace and scroll. The network program controlstoken-ring network communications, including establishing a terminalpolling address when the transaction terminal becomes active, detectingPOLL tokens addressed to the transaction terminal, building and sendingNODATA and TXDATA answers, and receiving RXDATA tokens containingresponse data for the transaction.

LCD module 136 is a self-contained liquid crystal display module thatincludes liquid crystal display 124, and provides many display controlfunctions internally. Display 124 is arranged in two lines of 20characters each, with the internal 80-character display data registerproviding 40 characters of display memory for each line. Each line isindependently scrolled under control of the LCD module in response tomicroprocessor mode control commands (for example, when the scroll keyon keypad 122 is depressed). In addition to the internal display dataregister, the LCD module includes an internal control/status register.Logically, these registers are treated as, respectively, data andcontrol/status ports. Data may be read to or written from the data port,while control is written to and status is read from the control/statusreport.

From above, the display control program in EPROM 134 provides thevarious mode control commands that invoke the display control functionsimplemented by the LCD module. For example, in response to appropriatemode control commands, the LCD module performs the necessary internaloperations to move the cursor, output the character under the cursor,write a character in the cursor position, delete a character in thecursor position, clear the display, and output sequentially allcharacters in the display data register (such as after the enter key isdepressed).

Microprocessor 130 provides four input/output ports 0-3. Port 0 isoutput only, and provides the higher order address bits A08-A12 over theAddress Bus (the 3 higher order bits A13-A15 of the 16-bit Z8microprocessor address are not used by the transaction terminal). Port 1is input/output, providing the lower order address bits A00-A07 andreceiving 8-bit data bytes over the Address/Data Bus. Port 2 is inputonly, and is coupled to the column/row matrix lines of the 4×4 keypadmatrix for keypad 122, i.e., column lines C0-C3 and row lines R0-R3.

Port 3 (0-7) is a multi-purpose input/output port. Pins 0 and 7 are aserial I/O port for an internal UART (universal asynchronous receivertransmitter). Pin 5 is an output drive enable line that controls thetransmit/receive state of differential line driver 138. Pin 4 is a datamemory DM line used to select either program memory (i.e., EPROM 134) ordata memory (i.e., LCD module 136). Pins 1-3 are an I/O port for acredit card reader (not used in the preferred embodiment), and Pin 6 isan output port for a buzzer.

In addition to the four I/O ports, microprocessor 130 provides anaddress strobe line AS, a data strobe line DS and read/write line R/W.

A clock circuit 131 includes a crystal oscillator that establishes a7.3728 MHz system clock. The Z8 microprocessor is clocked down (from its12 MHz specification) to accommodate the LCD module's response time.

Address latch 132 receives the lower order address bits A00-A07 frommicroprocessor port 1 over the Address/Data Bus during the first addresscycle. The address latch is enabled to latch these address bits by amicroprocessor address strobe provided through an inverter 142. Thelatched address bits A00-A07 are available at the output of addresslatch 132 which is coupled to the Address Bus.

EPROM 134 receives a 12-bit address A00-A12 from the Address Bus. Thelower order bits A00-A07 are provided by address latch 132, and areavailable on the Address Bus during the second address cycle when thehigher order bits A8-A12 are provided by microprocessor port 0 over theAddress Bus. Thus, EPROM 134 receives the complete 12-bit addressA00-A12 from the Address Bus during the second address cycle. Theaddressed data byte AD0-AD7 is available from the EPROM output port overthe Address/Data Bus and may be read when microprocessor 130 provides adata strobe DS to the chip enable CE input to the EPROM.

LCD module 136 includes an I/O port (pins D0-D7) coupled to theAddress/Data Bus (lines AD0-AD7). To connect either the display dataregister or the control/status register to the I/O port, Microprocessor130 selects either data port operation or control/status port operationwith a register select signal provided by the address bit A00 from theAddress Bus to the R/S input of the LCD module—if A00 is even (logic 0),the display data register is connected to the I/O port, and if A00 isodd (logic 1), the control/status register is connected. Read/writeoperation is selected by R/W signal from microprocessor 130 to the R/Winput to LCD module 136.

LCD module 136 is enabled for output over the Address/Data Bus by anenable signal from a NOR gate 146, which receives input from themicroprocessor's data strobe DS line and data memory DM line (port 3,pin 4). That is, LCD module 136 may be read only if both the data strobeand data memory lines are active. In contrast, EPROM 134 is enabled fora read operation only if the data strobe line is active while the datamemory line is inactive causing an active output from an inverter 144.In this manner, microprocessor 130 uses the data memory line to selectbetween program memory (EPROM 134) and data memory (LCD module 136).

A potentiometer 148 is used to adjust contrast for the LCD display 124.The potentiometer is connected between the pins +5 volts and ground onLCD module 136, with the potentiometer voltage being applied to thevoltage reference pin VREF.

To read instructions from EPROM 134, microprocessor 130 provides a12-bit address on the Address Bus—the lower order address bits A00-A07from port 1 through address latch 132, and the higher order address bitsA08-A12 from port 0. EPROM 134 is enabled for output by the data memoryline (port 3, pin 4) being held inactive resulting in an activeoutput-enable signal from inverter 144 to the EPROM. Conversely, LCDmodule 136 is disabled for a read operation because the inactive datamemory line insures an inactive signal from NOR gate 146 to the LCDmodule, thereby insuring that EPROM 134 has exclusive access to theAddress/Data Bus. During the read cycle, microprocessor 130 enablesEPROM 134 to output the addressed data byte by providing a data strobeDS to the chip-enable input to the EPROM.

To read display data from the display data register in LCD module 136,Microprocessor 130 executes a read display routine in the displaycontrol program stored in EPROM 134. Microprocessor 130 first disenablesEPROM 134 by holding the data memory line (port 3, pin 4) active,causing the output-enable output from inverter 146 to be inactive. LCDmodule 136 is then enabled for input/output when a microprocessor datastrobe drives active the output from NOR gate 148, which now has bothits inputs (DM and DS) active.

Once LCD module 136 has been given access to the Address/Data Bus, adisplay-data-register read operation is accomplished as follows.Microprocessor 130 outputs from port 1 an LCD mode control byteincluding a register select bit A00 over the Address/Data Bus. Theregister select bit is coupled through address latch 132 and the AddressBus to the RS input to LCD module 136 which selects bit is in the C/Sstate, causing LCD module 136 to select the control/status register forI/O access to the Address/Data Bus. Microprocessor 130 also places itsread/write R/W line in the write state, so that the mode control bytecan be written into the control/status register. Microprocessor 130 thenprovides a data strobe DS that enables LCD module 136 to latch the modecontrol byte from the Address/Data Bus into the control/status register.

In accordance with this mode control command, LCD module 136 places anot-ready status byte in the control status register, makes thedesignated display character in the display data register available foroutput on the Address/Data Bus, and then places a ready status byte intothe control/status register. Microprocessor 130 switches the read/writeline to read (the control/status register is still selected for I/O),and then provides a data strobe DS to read the status byte in thecontrol/status register. (The microprocessor continually strokes the LCDModule until a ready status byte is returned from the control/statusregister.)

Microprocessor 130 then outputs a register select bit (A00) that causesLCD module 136 to select the display data register for output. Finally,the microprocessor provides a data strobe to read the first display datacharacter over the Address/Data Bus into port 1.

This procedure—select control/status, read status, select display data,read display data—is continued until all requested display datacharacters have been read. That is, microprocessor 130 first reads thestatus register to determine when LCD module 136 is ready (i.e., whenthe next display data character is available), and then reads thecharacter.

The procedure by which microprocessor 130 provides display datacharacters for display by LCD module 136, writing the characters intothe display data register, is analogous to the procedure for readingdisplay data characters. Executing a write display routine in thedisplay control program, microprocessor 136 first writes a correspondingmode control command into the control/status register of the LCD module,and then reads status to determine when the LCD module is ready.Microprocessor 130 then selects the display data register, and writesthe first display data character over the Address/Data Bus.Microprocessor 130 reads the status register to confirm that the LCDmodule is ready prior to writing the next display data character. Thisprocedure of reading the status register and then writing a display datacharacter is continued until all display data characters have beenwritten.

Differential transceiver 138 controls data communications over thenetwork bus 118 connected to connector 140. The RS485 communicationsprotocol is implemented by microprocessor 130 executing the networkcommunications program stored in EPROM 134. Port 3 of microprocessor 130is used as a communications port, with pins 0 and 7 providing a serialI/O port, and pin 5 providing a transceiver drive enable line through aninverter 152 (the differential transceiver is in the transmit mode ifthe signal is active, and in the receive mode if the signal isinactive).

On the network side of differential transceiver 138, signal lines 6 and7 are coupled, respectively, to the network bus signal lines SIG+ andSIG−. These signal lines are coupled to the +12 volt line throughopposite sides of a protective diode network 154.

While waiting for a token (either POLL or RXDATA) over the network bus,microprocessor 130 holds the transceiver drive enable line inactive,thereby placing differential transceiver 138 in the receive mode. When atoken is received through differential transceiver 138 into the serialI/O port (port 3, pins 0 and 7), microprocessor 138 switches thetransceiver drive enable line active and transmits either a TXDATA orNODATA answer via the serial I/O port and the differential transceiver.

Keypad input is accomplished in a conventional manner using a 4×4 keypadmatrix with column lines C0-C3 and row lines R0-R3. Key-struck decodingis accomplished as follows. Column lines C0-C3 are normally held high bya resistor network 160, while microprocessor 130 (port 2) holds the rowlines R0-R3 low. When a key is struck, the corresponding column line isbrought into contact with that key's row line, and the column line isbrought low, which is detected by microprocessor 130. The microprocessorthen switches the port 2 lines high, and sequentially drops a row linelow until the key-struck column line goes low, thereby identifying thekey that was struck by its row/column intersection.

Keypad control functions, such as debouncing and N-key rollover areaccomplished in a conventional manner using program routines of thekeypad control program stored in EPROM 134.

Power for the transaction terminal is provided by a voltage regulator165 that receives +12 volts from the +12 volt line of the network bus.Voltage regulator 165 provides a stable +5 volt logic level.

A transaction terminal is initialized as follows. At power on, voltageregulator 165 provides a reset signal to microprocessor 130 when the +5volt logic level is stable. Microprocessor 130 turns port 0 off, so thatthe Address Bus is controlled by the low-current resistor network 160,which holds the Address Bus lines A08-A12 high.

Microprocessor 130 outputs from port 1 an initialization address overthe Address/Data Bus, which is latched into address latch 132 and placedon the Address Bus. EPROM 134 receives the initialization addressA00-A12 (with bits A08-A12 being held high by resistor network 160), andmakes the addressed instruction available at its data output port.Microprocessor 130 then reads the first instruction over theAddress/Data Bus.

Port 0 is turned on, so that resistor network 160 no longer controls theaddress lines A08-A12 of the Address Bus, and normal operation commencesunder control of microprocessor 130.

1.4. Multiple-Store Configuration. As shown in FIG. 1, for businesseswith multiple stores, a check transaction processing system 110 islocated in each store.

One store is designated as a “host” system, and the other stores aredesignated as “remote” systems. The host system coordinates the globalexchange of check verification data and other customer information, butotherwise operates as a local system for that store in the same manneras the remote systems. Operation as a host does not affect concurrentlocal operation, i.e., host/remote status is transparent to the checktransaction processing operation at each store.

Each store operates relatively autonomously in developing andmaintaining its local customer database and providing check transactionprocessing. However, the stores are also able to globally exchangecertain customer information useful to all of the stores, particularlyfor purposes of check verification. For example, while it is probablyunnecessary for the stores to exchange information about customers whotypically frequent only a single store and do not present checktransaction problems, the stores will probably want to exchangeinformation about customers who have written bad checks at one or morestores, or who are in a cautionary status as new customers. Such aglobal exchange of customer information reduces the likelihood that thebusiness will experience a significant loss from a concerted bad checkwriter.

Each store's customer database is updated with both local and globalcustomer information. Each local check transaction processing system110, including the designated host system, continually updates itscustomer database with local customer information, either automaticallythrough processing check transactions or through operator-input ofcustomer status data (such as negative status information). At regularintervals, each remote system transfers to the host selected customerinformation (such as negative and caution status information). The hostupdates its customer database with this customer information, andtransfers back to each remote system global customer information fromall remote systems. Each remote system then updates its customerdatabase with this global customer information.

1.5. Exemplary Components. The detailed specifications for transactionprocessor 112, and its associated disk storage 114, and networkcommunications interface 116 are not critical to this invention, being amatter of design choice. For the preferred embodiment, transactionprocessor 112 uses a Western Digital Processor Board Model No.WD286-WDM2 based on the Intel 80286 processor chip. Disk storage unit114 is a Seagate Technologies Model ST225, and communications interface116 is Sealevel Systems RS485 Communications Board Model No. SIO-485.The transaction processor runs MSDOS 3.3.

The detailed specification for point-of-sale transaction terminals 120is not critical to this invention, being a matter of routine designspecification. For the preferred embodiment, transaction terminal 120includes the following components: Microprocessor 130 Zilog Z8(86C9112PSC) Address Latch 132 74HC373 EPROM 134 27C64 LCD Module 136Optrex DMC16207 4 × 4 Keypad Standard 4 × 4 matrix Diff. Transceiver75176 (R5485 compatible) Voltage Regulator LM2925

Alternative similar point-of-sale units are commercially available, suchas from Omron Business Systems Model No. C.A.T. 90.

2.0 FUNCTIONAL DESCRIPTION

As diagrammed in FIG. 3 a, the check transaction processing systemperforms the following general functions:

-   -   (a) Verification (with Transactional Update) and Query    -   (b) Local Status Update    -   (c) Global Update    -   (d) Event-driven activities    -   (e) Customer database purge    -   (f) Host/Remote communications        as well as the customer database management operations necessary        to support these functions. In addition, certain system        information and diagnostic functions are performed.

The verification function involves sending a request for checktransaction verification from a point-of-sale transaction terminal tothe transaction processor, which performs the necessary databaseoperations to process the request, update the customer database withtransactional data (such as frequency and dollar amount) to reflect thecurrent transaction, and return an appropriate response. The localstatus update function involves continuously inputting customer statuschanges (particularly to reflect bad check experience) for customers ina store's local customer database. The global update function, formultiple-store systems, involves continuously transferring among thestores selected customer information (preferably caution and negativestatus information). The purge function involves removing obsolete orunwanted customer records from the customer database based on specifiedpurging criteria. The event-driven activities involve certain databasemanagement functions (such as purge and backup), as well as host/remotecommunications for global update, automatically performed at regularintervals.

2.1. Database Structure. The customer database includes all customerinformation used and maintained by the check transaction processingsystem. The customer database comprises two separate files containingcustomer information: the customer file and the negative status file. Inaddition, a system control file contains transactional limits usedduring check verification and purge limits.

The customer file contains customer records that include the followingcustomer information: Field Description Check ID Customer checkingaccount number Verification Status POSITIVE, NEGATIVE, CAUTION, CASHONLY, or STOLEN User Flags User assigned flags that designate a customeras PREAPPROVED for check transactions regardless of any transactionallimits, or as being authorized for check transactions on a MANAGER ONLYapproval basis regardless of actual status Transfer Date/Time Date/timethe customer record was last accessed and updated (written to disk),used in host/remote transfers for global update (transfers from host toremote generally do not affect this date) Access Date/Time Lastdate/time the customer record was accessed and updated (a query functiondoes not change the access date/time) Status Change Date Date/timecustomer status changed (e.g., CAUTION to POSITIVE) DWT FrequencyDay/Week/Total values for transaction frequency (updated transactionallyduring check verification and globally) DWT $Amount Day/Week/Totaldollar amounts (updated transactionally during check verification andglobally) Previous Status Customer's previous status (such as CAUTIONprior to being rolled POSITIVE) Frequency Since Total number of checktransactions Transfer since the last global transfer $Amount Since Totaldollar volume since the last Transfer global transfer

The file specification for a customer record is set forth in Table 1 atthe end of the specification.

The customer file is indexed by (a) check ID, and (b) status/transferdate/check ID.

The preferred intervals for maintaining frequency and dollar amounttransactional data are Day/Week/Total, where the day is the current24-hour period, the week is the previous 7 days, and the total is thetotal since the customer's first check transaction. The DWT designationwill be used throughout this specification to indicate the threeseparate values for either Frequency or $Amount. Preferably, DWTFrequency and $Amounts are maintained on a global basis, so that forthose records that have been globally updated (such as NEGATIVE andCAUTION status customer records), the DWT values will be global ratherthan local. Alternatively, separate local and global DWT transactionaldata can be maintained in the customer records, as shown in Table 2.

A customer can be assigned one of five check verification statusdesignations: Status Description CAUTION The customer is a new customer,and a specified check clearance interval since the customer's firstcheck transaction has not passed NEGATIVE The customer has one or moreoutstanding bad checks at any store location POSITIVE The specifiedcheck clearance interval since the customer's first check transactionhas passed, and no bad checks are outstanding at any store location CASHONLY The customer is not authorized to cash checks, even though no badchecks are outstanding STOLEN The customer has reported stolen checks

Customer status is assigned during customer record creation, and thenupdated (transactionally, locally or globally) to reflect changes incustomer status, such as due to elapsed time between check transactionsor bad check history.

In addition, the local update function can be used to assign to acustomer either of the following user flag designations, which overridenormal status responses to check verification or status query requests:User Flag Description PREAPPROVED The customer has been pre-approved forcheck transactions that may otherwise exceed certain transactionallimits applied even to customers with POSITIVE status MANAGER ONLY Thecustomer is not authorized to cash checks without manager approval, eventhough no bad checks are outstanding

In response to a check verification (or status query) request entered ata transaction terminal, the transaction processor returns a responsewith either customer status, or if specified transactional limits havebeen exceeded, a CALL MANAGER directive, unless the PREAPPROVED orMANAGER ONLY user flags in the customers record have been set.Generally, a check transaction will be authorized if the customer has aPOSITIVE status or is PREAPPROVED, will require manager approval forMANAGER ONLY regardless of status, and will be refused if customerstatus is NEGATIVE, CASH ONLY or STOLEN. Check authorization forcustomers with CAUTION status is a matter of store policy. For example,check authorization can depend upon DWT Frequency or $Amount, or thetype of check transaction (such as amount of purchase only), or uponhaving the check transaction approved by a store manager.

The CALL MANAGER directive is not a verification status contained in acustomer record, but rather, is the response to a verification requestif, for any status (including POSITIVE), the current check transactioncauses transactional limits specified in the system control file for DWTFrequency and $Amount to be exceeded.

The negative status file contains negative status records that includethe following customer information (by location for multiple storesystems): Field Description Check ID Customer checking account numberLocation The location identification for the store (each store having aNEGATIVE and/or CASH ONLY status history is assigned a separate negativestatus record) NEGATIVE Status Active -- That location has a bad checkoutstanding Inactive -- That location has no bad checks outstanding CASHONLY Status Active -- That location has designated the customer as CASHONLY Inactive -- That location has not designated the customer CASH ONLYAccess Date/Time Last date/time the negative status record was accessedand updated (a query function does not change this date) NEGATIVEDate/Time Date/time the status first became NEGATIVE CASH ONLY Date/TimeDate/time the status first became CASH ONLY BAD Frequency Total numberof bad checks at that location BAD $Amount Total dollar amount in badchecks at that location

The file specification for a negative status record is set forth inTable 2 at the end of the specification.

The negative status file is indexed by (a) status/check ID/location, and(b) status/access date/check ID/location.

The negative status file supplements the customer file for thosecustomers with a bad check history by recording BAD Frequency/$Amount bylocation, and also maintains CASH ONLY status by location.

The system control file includes the following selectable limits: LimitsDescription CAUTION/POSITIVE This limit defines a check clearanceinterval for new customers who will be rolled for check transactionsafter that interval (assuming the first check is not returned) CALLMANAGER Separate DWT limits are provided by status for both Frequencyand $Amount, defining the transactional limits applied to each statusPURGE Separate Purge limits are specified for each of the five customerstatus designations; also used to define a Reset/CAUTION interval

The file specification for the system control file is contained in Table3 at the end of the specification.

These limits are all specified by the user during system configuration.The CALL MANAGER limits are used to override the normal customer statusresponse to a verification request when any DWT Frequency/$Amount CALLMANAGER limit is exceeded by the current check transaction. As analternative to using the Purge limits for deleting customer records witha specified (by status) degree of obsolescence, these limits can be usedto roll a POSITIVE or any other status back to CAUTION if the specifiedReset/CAUTION interval between check transactions (defined by thecorresponding Purge limit) has passed. In addition to these limits, thesystem control file contains various system information.

The specific design of the customer database, and in particular the filespecifications for the customer file, negative status file, and systemcontrol file, are not critical to the invention, being a matter ofdesign choice. Any customer database will likely comprise customerrecords identified by the customer check ID, and include selectedtransactional/customer information; such as check verification statusand transactional frequency and dollar volume over specified intervals.

2.2. Function Codes. The specific functions available in the checktransaction processing system are invoked by entering at a transactionterminal a request including an appropriate function code (function keyplus code number) and request data (such as check ID and $Amount).

The specific check transaction processing functions are set forth inTable 4 at the end of the specification, with each function beingdescribed in terms of function code, description, keypad input, andkeypad output. These functions are in the following general categories:Function Description (Function Code) Verify Request check verificationstatus for the current check transaction (F55) (updating thecorresponding customer record to reflect the current transaction) QueryRequest information about status (F1), NEGATIVE status and locations(F2, F3, F4) and DWT Frequency and $Amounts (F5) (the customer databaseis not updated) Input Status Add (F40, F41, F44) and Delete (F60, F61,F62, F63, and F66) the status values CASH ONLY, STOLEN and NEGATIVE, andAdd (F42, F43) and Delete (F62, F63) PRE-APPROVED and MANAGER ONLY userflags Event Activity Start (F950) and Stop (F951) an event activity,request event time (F952), and request activity status (F953) SystemRequest certain system information, Information including memory usage(F902), disk usage (F903), customer file size (F904), negative statusfile size (F905), CAUTION/POSITIVE roll period (F906, F907), Purgelimits (F906, F908-F912), CALL MANAGER limits (F906, F913-F917) SystemRequest system diagnostic Diagnostics functions, including log-in/out(F77/F88), keypad debug (F960), modem debug (F970), data manager debug(F980), open/close customer database (F981/F982) and shutdown (F999)

2.3. Verify/Query. The verify function is used both to provideverification status (such as POSITIVE, NEGATIVE or CAUTION) for a checktransaction, and to update the transactional data in the customerdatabase. The principal difference between the verify and queryfunctions is that, while both functions retrieve the specified (by checkID) customer record (or in the case of query, the negative statusrecord) to provide an appropriate response, only the verify functionactually updates the customer database by writing the updated customerrecord back to disk.

FIG. 4 diagrams the check verification function. A check verificationfunction is initiated (202) by entering a verify request (checkID/function code/$Amount) from a transaction terminal, which istransmitted to the transaction processor for check transactionprocessing and to determine the appropriate check verification response.

The transaction processor uses the check ID to search (204) the customerfile for a corresponding customer record, which is retrieved (206), orif it doesn't exist, created (208) with a CAUTION status. The customerrecord is updated (210) by rolling Access Date/Time, Status and DWTFrequency and $Amount to reflect the current access date/time.

First, the Access Date/Time in the customer record is rolled (212)forward to the date/time for the current check transaction, establishingthe transaction interval, i.e. the time elapsed since the customer'slast check transaction.

Next, for a given status, the transaction interval is compared (214)with a corresponding selected reset/CAUTION interval—if the transactioninterval is such that the reset/CAUTION interval for the customer'sstatus is exceeded, Status is rolled (215) to CAUTION, and the customeris treated as a new customer from that time. If the customer record hasa CAUTION status, the transaction interval is compared (216) with aselected CAUTION/POSITIVE limit defining a check clearance period—ifthis check clearance period has passed, the CAUTION status is rolled(217) POSITIVE.

The last roll/update operation is to roll (218) the DWT values forFrequency and $Amount to reflect the current access date/time.

After the roll/update operation (210) updates the customer record toreflect the current access date/time, the current transactional data areadded (220) by incrementing DWT Frequency and adding the transaction$Amount to the corresponding DWT $Amount. The DWT transactional data inthe updated customer record now reflects the current transaction.

Next, the user flags in the customer record are checked (222)—if theMANAGER ONLY flag is set, a MANAGER ONLY response is returned (225)regardless of status, while if the PREAPPROVED flag is set, the normalstatus response (POSITIVE) is returned (226) regardless of anytransactional CALL MANAGER limits.

Finally, DWT Frequency/$Amount are compared (228) with the CALL MANAGERlimits for the customer's status to determine whether any of theselimits are exceeded. If not, a normal response with the customer's checkverification status is returned (226); if any limit is exceeded, a CALLMANAGER response is returned (229).

For the status query function, the same roll/update operation (210) isperformed to provide a customer record with updated Access Date/Time,Status and DWT Frequency/$Amount from which an appropriate statusresponse can be derived. However, the updated customer record is onlyused to derive the response to the query request—the updated record isnot written back to disk, so the customer database is not updated.

2.4. Local Status Update. Local status update of the customer databaseis accomplished by inputting certain status (and user flag) informationto reflect bad check experience or store policy.

Status input functions are used to Add or Delete the status valuesNEGATIVE, CASH ONLY and STOLEN. Typically these functions will involvemodifying the Status of an existing customer record and/or negativestatus record, although new records may be created. In addition, localinput functions are used to Add or Delete user flags that designate thecustomer as PREAPPROVED or MANAGER ONLY.

For multiple store systems, a separate negative status record is keptfor each location having a NEGATIVE and/or CASH ONLY status history.Thus, assuming negative status records are transferred during the globalupdate function, each store's negative status file will contain separatenegative status records for the various locations, sometimes for thesame customer. Generally, a store can only affect through the localupdate function, negative status records for its location.

For each status input function, the update operation for the customerrecord includes the roll/update operation described in connection withFIG. 4 (210) to reflect the current access (update) to the customerrecord (which is written to disk to update the customer file).

FIG. 5 diagrams the local status input function for Add/Delete NEGATIVEstatus. A store uses this operation only for the negative status recordsfor that location, and only when all bad checks have been recovered orotherwise resolved. For the Add NEGATIVE status function, thecorresponding negative status record for that location is retrieved orcreated (230), and NEGATIVE status is set (232) Active and BADFrequency/$Amount is adjusted (233) by adding the current bad checktransaction. The corresponding customer record is then retrieved orcreated (235), and updated by the roll/update operation (238) but withstatus set (239) to NEGATIVE.

For the Delete NEGATIVE Status function, the corresponding negativestatus record is retrieved (230), and NEGATIVE Status is set (232) toInactive and BAD Frequency/$Amount are set (233) to zero. If thatcustomer has no other bad checks outstanding at any location (i.e., noother negative status records with NEGATIVE Status Active) (236), thenthe corresponding customer record is retrieved or created (237) andupdated by the roll/update operation (238), but with status rolled (239)to its previous state (i.e., prior to becoming NEGATIVE).

For status input functions that Add/Delete CASH ONLY (which status isalso kept by location in negative status file), the basic operation isthe same as for Add/Delete NEGATIVE except that the BADFrequency/$Amount data are unaffected.

For the status input functions that Add/Delete STOLEN, only the customerfile need be updated. For the Add STOLEN function, the correspondingcustomer record is updated in accordance with the roll/update operation,but with status rolled to STOLEN. For the Delete STOLEN function, thecorresponding customer record is updated and rolled to CAUTION.

For the user flag input functions that Add/Delete PREAPPROVED or MANAGERONLY, again, only the corresponding customer record need be updated.

2.5. Global Update. For multiple-store systems, the global updatefunction is used to coordinate the exchange of certain customerinformation among the individual stores.

Global update is accomplished by file (record) transfers between eachremote system and the host system. The host system receives selectedcustomer records and negative status records from each remote, updatesits customer database, and then transmits globally updated records backto each of the remotes. Each remote is able to maintain a local customerdatabase, supplemented with selected global customer information deemedto be useful to all stores in the system.

The type of customer information transferred by the global updatefunction is based on store management policies. The recommended approachto exchanging global customer information is as follows:

-   -   (a) Negative Status Records—All NEGATIVE status records        (NEGATIVE or CASH ONLY status) accessed (created or updated)        since the last transfer; and    -   (b) Customer Records—All customer records with status values        CAUTION, NEGATIVE, CASH ONLY and STOLEN accessed (created or        updated) since the last file transfer;    -   (c) POSITIVE status records (even those designated MANAGER ONLY)        are not recommended for global transfer.        As a result, the local customer database contains negative        status records (including NEGATIVE and CASH ONLY status and BAD        Frequency/$Amount) for all store locations (although each remote        system only transfers to the host the negative status records        for its location). For those customer records transferred, DWT        Frequency/$Amounts can be maintained either globally or locally        and globally. That is, a store may decide not to maintain both        global and local transaction data since, for regular customers        that primarily frequent that store (i.e., the customers of        primary interest) global and local transaction data are        essentially the same anyway. On the other hand, a store may want        to keep its local transaction data completely separate from the        global data attributable to all stores.

The host/remote file transfers that support global update areaccomplished automatically through the event/activity function describedin Section 2.7. Generally, for each remote system, host/remote filetransfer constitutes an activity automatically invoked at predeterminedregular event intervals. This procedure insures that the local customerdatabases are regularly supplemented with globally updated status andother customer information affecting check verification.

A global update session is initiated by a remote system. The remotetransmits only those negative status or selected customer recordsaccessed (updated) since the last host/remote file transfer. Since aremote only updates (or creates) negative status records for itslocation (although negative status records for other locations may bequeried), a remote only transfers those local records (but will receiveback from the host recently updated negative status records for alllocations). And, only those updated customer records meeting theselected status criteria are transferred (i.e., POSITIVE status recordsare not transferred, even if designated MANAGER ONLY).

Negative status records are extracted using the index[status/transfer/date/ID/location], while customer records are extractedusing the index [status/access date/ID].

FIG. 6 a diagrams the host global update function by which the hostsystem receives recently updated negative status and customer records,and performs a global update of its customer database. For remotenegative status records (remote location only), the host retrieves orcreates (240) a corresponding host record, and sets (243, 244) hoststatus (NEGATIVE/CASH ONLY, ACTIVE/INACTIVE) and host BADFrequency/$Amount equal to the corresponding remote values. For remotecustomer records, the host retrieves or creates a corresponding hostrecord, and updates existing host records using the roll operation(246). Host and Remote status are compared, and if different, the hostassigns status (247) according to predetermined status arbitrationcriteria. The host then adds (248) the Frequency/$Amount accumulated atthe remote since last transfer to the Host DWT Frequency/$Amount, andselects (249) the greater of host/remote DWT data as correct, updatingthe host record accordingly.

After global update of the host customer database, the host transmits tothe remote all negative status records and selected customer recordsaccessed (updated) at the host since the previous transfer. Becauseevery remote record transferred to the host caused a corresponding hostrecord to be created or updated, and therefore accessed, thehost-to-remote file transfer necessarily includes all host recordscorresponding to the remote records transferred to the host during thatsession. In particular, host negative status records for all locations,meeting the recently accessed transfer criteria, are transferred to theremote. For negative status records from other locations, the remotemerely copies (253) the host record (remote location records receivedfrom the host are necessarily the same as the remote record). Forcustomer records, the remote first rolls (254) the DWT Frequency and$Amount. If host DWT Frequency/$Amount is less than the correspondingremote DWT data (255), the remote rolls (256) access data to insure thatthe remote record is transferred back to the host during the next globalupdate transfer session (to update the corresponding host record withthe greater DWD data); otherwise, the remote selects (257) the host DWTdata. That is, the global update function assumes that the greater DWTFrequency/$Amount is correct. Finally, the remote compares host/remotestatus, and if different, assigns status (258) according topredetermined status arbitration criteria.

2.6. Purge. The customer database purge function allows a store toorient its customer database toward active customers, stabilizing thedatabase size by deleting certain customer records and negative statusrecords deemed to be obsolete.

During database purge, customer records or negative status records witha given status are read, and the access data/time is compared with thecorresponding purge limit from the system control file. Records notaccessed during the interval defined by the purge limit are deleted.

Implementing the purge function is optional as a matter of store policy.For the preferred embodiment, the purge limits are also used to define areset/CAUTION interval (described in connection with FIG. 4). If arecord is not accessed during that interval, its status is rolled toCAUTION. Thus, the check transaction processing system defaults to thereset/CAUTION operation if the purge function is not operational.

The purge limits are a matter of design selection. The following purgelimits are recommended: CAUTION  90 days POSITIVE 180 days NEGATIVE 360days CASH ONLY 360 days STOLEN 360 daysBecause customer record status is not rolled automatically from CAUTIONto POSITIVE, but only as a result of a transaction in which the accessdate/time is also rolled current, the customer database maintains anaccurate record of CAUTION status for those first-time customers who donot return after the check clearance interval. Those CAUTION statuscustomers who do not return to a store within a reasonable period oftime can be eliminated from the customer database. Likewise, POSITIVEstatus customers who stop transacting business with a store can beeliminated from the active customer database.

Selected purge limits are entered into the system control file duringsystem installation/configuration. If the purge function is selected,performing it automatically as an event-driven activity (described inSection 2.7) is recommended.

2.7. Event/Activities. Event-driven activities are performedautomatically by the check transaction processing system to implementcertain functions without operator intervention.

The configuration and timing of these activities is a matter of routinedesign selection. The following event-driven activities, and theassociated event intervals, are recommended: Host/Remote File TransferEvery 15 minutes System Backup Every 10 minutes Purge Every 24 hoursIn addition, certain report functions can be made automatic asevent-driven activities, such as reporting every day all customerrecords with CAUTION or NEGATIVE status.

The specified event-driven activities and associated event intervals arecontained in an event table established during systeminstallation/configuration. These activities are then executed inbackground at the designated event times without user intervention, andwithout affecting other foreground functions such as check verification.Once the event table is configured, the various activities may bestarted or stopped by invoking appropriate functions from a transactionterminal (functions F950 and F951 in Table 4).

For multiple-store systems, performing the host/remote file transfersnecessary for global update on a regular, event-driven basis insuresthat CAUTION/NEGATIVE status information for check verification purposesis kept current throughout the system. Performing such transfers atrelatively short intervals keeps the individual host/remotecommunications sessions sufficiently short that other functions, such ascheck verification, are not significantly affected. Moreover, performinghost/remote file transfers on a regular basis at short intervals helpsguard against fraudulent bad check passing schemes.

Regularly, purging the customer database facilitates databasestabilization, and focuses the database on reasonably regular customers.The need for regular, and often, event-driven driven backup is obvious,and is not burdensome of system computing resources because only thosecustomer records actually updated during the short interval betweenbackup events need be backed up.

2.8 Communications. The communications function is primarily used tosupport host/remote file transfers for global update in multiple-storesystems. In addition, the communications function can be used for remotediagnostic operations.

The communications function is implemented in a conventional manner.Both the implementation of the communications function and the mode ofcommunications (such as using modem communications over dial up lines)are a matter of routine design selection. Implementing thecommunications function so as to be essentially transparent to the localoperation of the remote and host check transaction processing systems isrecommended (see Section 3.6).

2.9. System. Certain system diagnostic and system information functionsare available to users of the check transaction processing system.

These system functions are not critical to the inventory but are amatter of routine design selection. The recommended system functions areidentified in Section 2.2 and Table 4, and include querying the customerdatabase and system control file, obtaining disk usage and file sizeinformation, starting/stopping activities in the event file, andcontrolling certain keypad and modem configuration functions, as well ascontrolling certain system level functions such as log-on, log-off,open/close database, debug and system shutdown. In particular, thesesystem functions are useful to store supervisory personnel for queryingthe customer database and for controlling event-driven activities, andto vendor support personnel for remote diagnostic purposes.

2.10. Risk Management. The check transaction processing system enables astore to adopt a risk management approach to check verification.Specifically, through selection of the CALL MANAGER limits for eachstatus (including POSITIVE) a store has considerable flexibility inadjusting its check authorization policy to accommodate the differentrisks presented by different customers, both in terms of bad check risksand recovery risk.

Adopting specific risk management procedures for check verification is amatter of store policy implemented by routine design selection. Inaddition to selecting the CALL MANAGER transactional limits for eachstatus, the reset/CAUTION interval can be selected to force customerswho do not return for that interval into a CAUTION status. Moreover, theuser flags—PREAPPROVED and MANAGER ONLY—can be used to assign specialcheck verification treatment to selected customers regardless of statusor transactional (CALL MANAGER) limits.

Adopting risk management approach to check verification throughselecting transactional CALL MANAGER limits enables each store to make apolicy decision about the degree of risk the store is willing to takewithin a given interval. Moreover, this approach can be tailored to thespecific business climate of the store in terms of dollar volume,profitably, customer base and management philosophy. By specifyingtransactional CALL MANAGER limits in terms of status, frequency, dollaramount and transaction interval, the store's risk management approach tocheck verification can reflect statistical patterns for badcheck/recovery risks.

For example, frequency and dollar volume limits are important for theCAUTION status to reduce the risk that a store will be hit by aconcerted bad check scheme. (Global update is particularly important inthis area.) Depending on past experience with its typical customer, orstore policy, a new customer can be restricted in terms of numbers ofchecks and/or dollar volume during the selected check clearanceinterval.

Frequency and dollar volume limits are just as important for thePOSITIVE status. A store shouldn't assume any significant risk in termsof dollar volume (either for a current transaction or over a givenrelatively short interval such as a week) just because a customer hashad one or a few checks clear. That is, total historical checktransaction frequency is a significant factor in assessing the risk ofcashing a given check; both in terms of likelihood that the check is badand likelihood that a bad check will be recovered.

2.11. Customer Information Reporting. The check transaction processingsystem allows a store to build and maintain a customer databasecontaining customer information useful for identifying new customers anddeveloping customer profiles, in addition to its use for checkverification.

Reporting customer information, such as verification status and DWTFrequency/$Amounts, is a matter of routine design selection and storepolicy.

Customer information reports are recommended (a) to identify newcustomers, and (b) to develop customer profiles, both of which can beused in targeting marketing, advertising and promotional programs, andfor other customer relations purposes. Specifically, new customers areidentified by regularly reporting customer records with a CAUTIONstatus. Regular customers are identified by reporting customer recordsbased on DWT Frequency data, while the level of a customer's business isidentified by reporting customer records based on DWT $Amount data.Additional customer information that can be readily collected in thecustomer records includes zip code and marital status information usefulin demographic analysis.

The check transaction processing system permits the customer informationcontained in the customer database to be collected in an unobtrusive andefficient manner during high volume check transactions.

3.0 PROGRAM DESCRIPTION

The various check transaction processing functions described in Section2.0 are implemented using a check transaction processing system (“CTPS”)program executed by the transaction processor.

The CTPS Program must implement several operations in real time:

-   -   (a) transaction terminal network communications, including        communicating verification requests and the corresponding        responses;    -   (b) database operations, including responding to verification        requests and updating the customer database;    -   (c) event-driven activities, including global update, which must        execute in the background while the check verification function        is executing; and    -   (d) host/remote communications to support global update.        Moreover, while the purge function may be run after-hours as a        batch operation, system backup should be executed at regular        intervals throughout a business day as an event-driven        background activity.

To achieve acceptable performance using a 286-class engine for thetransaction processor, the preferred embodiment of the CTPS Program usesa multi-tasking architecture. The various functions performed by theCTPS Program are implemented as separate program tasks executed by thetransaction processor in a multi-tasking mode. For the preferred systemconfiguration (described in connection with FIG. 1), a multi-taskingarchitecture for the CTPS Program is superior in performance toavailable alternatives, such as polled interrupts.

3.1. General. As shown in FIG. 7, the CTPS Program includes various taskprograms interfaced through a System Kernal. Since the preferred MS/DOSOperating System is not multi-tasking, the System Kernal is required toimplement (a) task switching, and (b) intertask communications. In thisoperating environment, the MS/DOS operating system is used only for diskfile I/O, with the System Kernal interfacing functionally to theindividual task programs as an operating system.

System Kernal 400 controls task switching, intertask messagecommunications (requests and responses), subtask spawning, and tasksynchronization using semaphores.

Data Manager Task 500 controls all database operations used in checktransaction processing functions (such as verification withtransactional update, query, local status update, global update andpurge), executing function requests from the other task programs (suchas the Terminal Manager Task and the Event Manager Task) and returningresponse data.

Terminal Manager Task 700 controls data communications over thetransaction terminal network, receiving function requests from thetransaction terminals and spawning terminal request subtasks thattransmit a request to an executing task (usually the Data Manager Task)and then build an appropriate response from the response data providedby that executing task.

Event Manager Task 800 implements activities designated for automaticexecution on an event-drive basis, such as host/remote file transfersfor global update, spawning a background event subtask at the specifiedevent time to execute the specified activities.

Modem Manager Task 900 controls telecommunications primarily forhost/remote file transfer for global update, but also for remotediagnostic purposes.

In addition to these check transaction processing tasks, a ScreenManager Task 950 and a System Utilities Task 960 are provided formaintenance and diagnostic purposes.

In general, for the Verify/Query and Local Status Update functions, theTerminal Manager Task sequentially polls the transaction terminals whichenter and transmit requests, such as:

Verify [Function Code/check ID/Function Code/$Amount]

Query [Function Code/check ID]

Add/Delete [Function Code/check ID/Status]

For each terminal request, the Terminal Manager Task spawns acorresponding terminal request subtask that dispatches the request to acorresponding function/request routine, which sends the request to theData Manager Task. The Data Manager Task executes the request, andnotifies the function/request routine (by a semaphore operation) thatresponse data is ready. The function/request routine then builds theappropriate response from the response data, and writes it into theterminal buffer for the requesting terminal. The Terminal Manager Tasksends the response to the requesting terminal in the next pollingsequence.

For the Global Update function, the Event Manager Task running in aremote system sequences through an event table, and at specified eventtimes and intervals, spawns a corresponding event subtask to execute theglobal update activities, i.e., send/receive customer records andnegative status records. The subtask dispatches to correspondingactivity routines, i.e. activities that send/receive customer andnegative status records. The send activity routines first request theremote Data Manager Task to retrieve records accessed since the previousglobal update, and then request the remote Modem Manager Task totransfer those records to the host Data Manager Task for global update.The receive activity routines first send requests for globally updatedrecords through the remote Modem Manager Task to the host Data ManagerTask, and then requests the remote Data Manager Task to globally updatethe remote customer database using the records returned by the host.

3.2. System Kernal. The System Kernal Program is implementedfunctionally by a multi-tasking module and a system services module.

The multi-tasking module controls resource allocation through taskswitching, with multi-task execution being implemented using standardcontext switching to swap task instructions/data between (a) the programand data memory areas allocated to the task, and (b) the task executionregisters (i.e., the program counter, stack and other specified andgeneral purpose registers). To implement intertask communications, themulti-task module allocates for each task data memory areas for requestand response data, and maintains a task control block that contains foreach task (a) task queues for intertask requests, and (b) semaphoreflags.

The system services module implements intertask communications throughcalls to the multi-task module. For intertask communication, the systemservices module implements semaphore operations on the allocatedsemaphore flags in the task control block.

Functionally, the System Kernal interfaces to the various task programsthat comprise the CTPS Program as a multi-tasking operating system. TheKernal performs four principal operations that establish a multi-taskingenvironment for the check transaction processing system:

-   -   (a) task switching;    -   (b) task control block management for task queues and        semaphores;    -   (c) intertask communication of task requests/responses using the        task control block and allocated data areas; and    -   (d) spawning subtasks.        The first two operations are performed by the multi-tasking        module, while the second two operations are performed by the        system services module.) In addition, the System Kernal manages        the system control file, and performs diagnostic and system        utility operations (these operations being implemented by the        system services module).

The specific program implementation of the System Kernal is not criticalto this invention, being a matter of routine design specification.Indeed, as described in Section 4.0., the System Kernal can be replacedwith a commercially available multi-tasking operating system.

For the preferred embodiment, the multi-tasking module is implementedwith a commercially available program, Time Slicer from Life BoatSystems. Time Slicer provides a conventional multi-tasking environment,including task switching (context switching) and task control blockmanagement (request queues and semaphore flags). These multi-taskingoperations are implemented in a conventional manner. Alternativemulti-tasking modules are commercially available.

At system initialization, the System Kernal allocates the task controlblock (queues and semaphores flags) and the data areas for the varioustasks. Thereafter, the System Kernal receives service requests from arequesting task addressed to a responding task and written into theSystem Kernal's request queue.

The requesting task builds a service request in the following format

-   -   responding task ID    -   requesting task ID    -   function code    -   address of request data    -   address for response data    -   stope semaphore        The function code is one of the function codes set forth in        Table 4. The addresses for the request and response data are        data memory locations allocated to the requesting task.

FIG. 8 diagrams the intertask communication and subtask call functionsimplemented by the System Kernal. The System Kernal continually monitors(402) the request queue, executing service requests on a first-infirst-out basis. The system kernal first determines (404) whether thenext-in-line request is a service request or a subtask request from arequesting task, or a stop request (indicating request executioncompleted) from a responding task.

In the case of an intertask service request, the system kernal builds(410) a corresponding intertask packet, and writes (412) the packet intothe responding task queue in the task control block. In the case ofsubtask request (which includes the subtask file name), the SystemKernal spawns (414) the specified subtask (which typically executes thecalled function using intertask service requests). In the case of a stoprequest from a responding task, the System Kernal sets (416) thespecified semaphore flag in the task control block, notifying therequesting task that request execution is complete and response data isready.

The intertask request packet built by the System Kernal is in thefollowing format:

requesting task ID

function code

address of request data

address for response data

semaphore flag

That is, the intertask request packet includes the same information ascontained in the service request from the requesting task, but withoutthe responding task ID. That identification is unnecessary since eachtask is assigned a specific allocation of address space for its taskqueue and semaphore flags in the task control block, and for its dataarea. The stop request is the intertask request packet, which the SystemKernal recognizes as a stop request when it appears in its requestqueue.

In general, intertask request execution is accomplished as follows: Eachtask monitors its task queue in the task control block. If the taskqueue does not contain a request, the task continues executing internalfunctions. When an intertask request packet is written into a task queueby the System Kernal (in response to a service request), the respondingtask reads the packet from the queue. The responding task decodes therequest packet, and dispatches the request to an execution routine(either directly or by first spawning a subtask that handlesdispatching). This execution routine reads the request data located inthe requesting task's data area at the address specified in theintertask request packet, and executes the requested function using therequest data. After request execution, the execution routine provides aresponse by writing response data to the specified address in therequesting task's data area, and sends a stop request (which is theintertask request packet) to the System Kernal indicating that requestexecution is complete and response data is ready. The System Kernalexecutes the stop request by setting the specified semaphore flag.

For example, in the case of a verification request entered at atransaction terminal, the Terminal Manager Task spawns (through theSystem Kernal) a terminal request subtask. The terminal request subtaskdispatches to a verification/request routine that sends a verificationrequest through the System Kernal to the Data Manager Task. The DataManager Task reads from its task queue the verification request (i.e.the intertask verification/request packet), and determines that averification function is requested. The Data Manager Task dispatches therequest to an verification execution routine that reads the request data(check ID and $Amount) from the specified request data address, andperforms the necessary customer database operations, includingretrieving or creating a corresponding customer record and updatingstatus and transactional data (DWT Frequency and $Amount) to reflect thecurrent transaction. The execution routine then writes the updatedcustomer record to the specified response data address, and sends a stoprequest (i.e., the intertask request packet) to the System Kernal. TheSystem Kernal sets the specified semaphore flag, and the terminalrequest subtask reads the customer record and builds an appropriateresponse that is sent to the terminal by the Terminal Manager Task.

3.3. Data Manager Task. The Data Manager Task manages the customerdatabase, maintaining the customer record file and negative statusrecord file, and the related indices. The Data Manager Task controls alldatabase operations for check transaction processing functions (such asverify/query and local and global update) and customer databasemanagement functions (such as backup and purge), including recordcreation, retrieval, modification and deletion.

The check transaction processing functions performed by the Data ManagerTask are, generally:

(a) Verify (with Transactional Update)

(b) Query

(c) Local Status Update

(d) Global Update (Host and Remote)

The verify, query, and local status update functions are invoked from atransaction terminal. The global update function is an activity invokedby the Event Manager Task.

For the preferred embodiment, the Data Manager Tasks interfaces to thedisk files (i.e., the customer, negative status and system controlfiles) through a commercially available library of database managementroutines, C-Tree from Faircom Software. The C-Tree library, in turn,uses the MS/DOS File System (DES) to handle disk file I/O. Theconfiguration of those routines to operate with the Data Manager Taskand the MS/DOS DES is a matter of routine design specification. Othersuch libraries of database management routines are commerciallyavailable.

At system initialization, the Data Manager Task opens the customer andnegative status files, and a password file (used for supervisorfunctions requiring a password).

FIG. 9 a is a program flow diagram for the Data Manager Task. The Taskcontinually monitors (502) its task queue for requests (intertaskrequest packets) written into the queue by the system kernal. Theserequests primarily involve database operations in connection with checktransaction processing functions, and are received from the TerminalManager Task (Verify/Query and Local Status Update) and the EventManager Task (Global Update, Purge and Backup). Some requests involvesystem diagnostic or information requests such as for disk or databaseinformation (see Section 2.2).

If no requests are in the Data Manager Task queue, it executes internalfunctions (503). When the Task receives a request, it performs thefollowing operations:

-   -   (a) reading (506) a function request packet from the task queue;    -   (b) decoding (506) the function code; and    -   (c) dispatching (508) the function request to a corresponding        function execution routine.        The function execution routine executes the function, performing        the necessary database operations, and upon completion, writes        appropriate response data into the location specified by the        requesting task, and then sends a stop request (the intertask        request packet) to the system kernal.

The various functions identified in FIG. 9A—Verify (510), Host GlobalUpdate (Negative Status) (600), Host Global Update (Customer) (630), andRemote Global Update (660)—are representative of the check transactionprocessing functions performed by the CTP Program. These functions, andthe associated execution routines, are described in detail in connectionwith FIGS. 9B-9H.

FIG. 9B is a program flow diagram for the Verify routine in the DataManager Task. After receiving and decoding the appropriate intertaskrequest packet from the Terminal Manager Task, the Data Manager Taskdispatches (508) to the Verify Execution Routine 510.

The Verify routine reads (512) the verification request data (check IDand $Amount) from the request data location specified in the intertaskrequest packet. The customer database is searched (514) using the checkID, and the corresponding customer record is retrieved (515) or created(516) with status set to CAUTION and DWT Frequency and $Amount set tozero.

The Verify routine then calls (520) a roll routine that updates statusand transactional data in the record to reflect the current accessdate/time. The Data Manager Task does not independently update customerrecords to make status and DWT Frequency/$Amount reflect a currentdate/time. Rather, the customer records are updated in real time as theyare accessed, such as during execution of verify and update functions.Because this roll/update operation is used by many of the functionexecution routines in the Data Manager Task, a separate routine isprovided and called by these routines.

FIG. 9 c is a program flow diagram for the roll routine. The routinefirst rolls (522) the Access Date/Time in the customer record to thecurrent date, and then calculates (524) the transaction interval, ie.the elapsed time since the customer's previous check transaction.

The purge limit for the customer's status is read (526) from the systemcontrol file and compared (528) with the transaction interval. If thetransaction interval exceeds the purge limit, a status roll subroutineis called (530) and instructed to roll the status of the customer recordto CAUTION. (This reset/CAUTION operation provides a default alternativeto the purge function which would delete those customer records withaccess dates that exceed the corresponding status purge limit.)

Next, the roll routine determines whether, for customer records with aCAUTION status, the predetermined check clearance period defined by theCAUTION/POSITIVE limit has passed. If the customer status is CAUTION(532), then the CAUTION/POSITIVE limit is read (534) from the systemcontrol file and compared (536) with the status change date, i.e., thedate on which the customer became a CAUTION, either because of aninitial check transaction or because of a roll to CAUTION (such asthrough the reset/CAUTION procedure in 526, 528 and 530). If the periodduring which the customer has been a CAUTION exceeds theCAUTION/POSITIVE period, then the status roll subroutine is called (537)and instructed to roll customer status to POSITIVE.

The roll routine then rolls (538) the DWT totals for both Frequency and$Amount to reflect the current access date.

The customer record is now updated to the current access date, the rollroutine having rolled/updated the Access Date/Time, Status and DWTFrequency and $Amount.

The status roll subroutine is called when any function routine rollscustomer status from one value to another. As part of the callinstruction, the status roll subroutine receives a new status, CAUTIONin the case of the reset/CAUTION operation. Program state-logic thendetermines whether the roll is allowable according to specified rollstate-logic: (a) if allowed, status is rolled to the specified newstatus; or (b) if not allowed, status is rolled to an allowable statusvalue, or is not rolled, in accordance with the roll state-logic. Thestatus roll subroutine then rolls the status change date in the customerrecord to the current date (if the subroutine effected a change instatus). Thus, for customer records in which the transaction intervalexceeds the status purge limit, the customer record is modified toreflect a CAUTION status with a corresponding status change date.

The roll routine returns (539) to the calling routine, in this case, theVerify routine in FIG. 9 b. The verify routine adds (540) to theroll/updated customer record the current transaction by incrementing DWTFrequency and adding the current $Amount to the DWT $Amount. Thecustomer record is now updated to reflect both the current access dateand the current transaction. The updated customer record (with itstransfer date updated current) is written (542) to disk, to update thecustomer database.

The updated customer record constitutes the response data for the verifyrequest, and the Verify routine writes (544) the record into theresponse data location specified in the intertask request packet.

Finally, the Verify routine sends (546) a stop request to the SystemKernal. The stop request comprises the intertask request packet receivedfrom the System Kernal by the Data Manager Task. The appearance of thispacket in the Kernal's service request queue notifies the Kernal thatrequest execution by the verify routine is complete. In response to thestop request, the System Kernal sets the semaphore flag specified in theintertask request packet to notify the Terminal Manager Task that theverification request is complete, and the response data is in thespecified location.

The query function is used to query the customer database, and retrievean updated customer record or updated negative status record from whichthe desired information may be extracted. For each query function, theData Manager Task dispatches to a corresponding query execution routinethat retrieves and updates the requested customer record or negativestatus record. The essential difference between the query routines andthe verify routine is that no current check transaction data isinvolved, and the updated record is not written to disk to update thecustomer database.

For example, in the case of a query for customer information (such asstatus and/or DWT transactional data), the Data Manager Task dispatchesthe intertask query request packet to the corresponding Query executionroutine. The routine reads the check ID from the specified location forthe request data, and initiates a search of the customer record file. Ifno corresponding customer record is found, the query routine returns anerror message response. If a corresponding customer record is retrieved,the Query routine calls the roll routine to update Access Date/Time,Status and DWT Frequency/$Amount. The roll/updated customer record iswritten to the specified location for the response data, and a stoprequest is sent to the System Kernal. The Query routine does not updatethe customer database by writing the updated customer record back todisk.

In addition to updating the customer database in real time through theverification operation, the Data Manager Task also implements thefollowing local status update functions:

Add/Delete NEGATIVE

Add/Delete CASH ONLY

Add/Delete STOLEN

Add/Delete PREAPPROVED

Add/Delete MANAGER ONLY

These functions are used to input customer status and user flaginformation.

For multiple store systems, negative status records are kept bylocation, i.e. each location creates a negative status record for anycustomer with NEGATIVE or CASH ONLY status at that location. GlobalUpdate causes the negative status file at each location to containnegative status records for each location (assuming negative statusrecords are selected for global update). Each location can accessthrough the Add/Delete NEGATIVE and CASH ONLY functions only thosenegative status records for its location. The query function can be usedto query negative status records from other locations.

FIG. 9 d is a program flow diagram for the add NEGATIVE local statusupdate function. After receiving and decoding the appropriate intertaskrequest packet from the Terminal Manager Task, the Data Manager Taskdispatches (508) to the Add NETATIVE execution routine (550).

The Add NEGATIVE routine reads (551) the request data (checkID/location/$Amount) from the location specified in the intertaskrequest packet. The negative status file is searched (552) for acorresponding negative status record, which is either retrieved (553) orcreated (554). If NEGATIVE status is Inactive (556), the status rollsubroutine in called (557) and instructed to roll to Active. The currentbad check data is then added (558) to the BAD Frequency and $Amounttotals for that location. The routine then writes (559) the updatednegative status record into the negative status file.

The customer file is searched (560) for the specified customer record,which is either retrieved (561) or created (562). The roll routine iscalled (564) to roll/update the customer record (Access Date/Time,Status and DWT Frequency/$Amount) as described in connection with FIG. 9c. After roll/update, the status roll subroutine is called (566) andinstructed to roll customer status NEGATIVE. The updated customer record(with its transfer date updated current) is then written (568) into thecustomer file.

After the add NEGATIVE function is accomplished, a confirmation responseis written (570) into the specified response data location, and a stoprequest is sent (572) to the System Kernal (which sets the specifiedsemaphore flag).

FIG. 9 e is a program flow diagram for the delete NEGATIVE function.After receiving and decoding the appropriate intertask request packetfrom the Terminal Manager Task, the Data Manager Task dispatches (508)to the Delete NEGATIVE execution routine (580).

For multiple-store systems, the Delete NEGATIVE function is usedaccording to the following criteria: (a) it is only used to deleteNEGATIVE status for the location requesting the delete NEGATIVEfunction; i.e., to change NEGATIVE status from Active to Inactive onlyin the negative status record for that location; and (b) it is only usedif all bad checks for that location have been paid off or otherwiseresolved. Thus, each location can only affect its own negative statusrecord—the global update function is used to distribute negative statusrecords among all locations.

The Delete NEGATIVE routine reads (581) the request data (checkID/location) from the location specified in the intertask requestpacket. The negative status file is searched (582), and the negativestatus record for that location is retrieved (584), if it exists. Thestatus roll subroutine is called (586) to roll NEGATIVE status fromActive to Inactive. The BAD Frequency and $Amount data are then deleted(587) indicating that all bad checks have been paid or otherwiseresolved.

Next, the routine determines (590) whether another negative statusrecord exists for that customer, i.e., whether the customer has aNEGATIVE status active at other locations. If the negative status filecontains no other negative status records for the customer, the customerfile is searched to retrieve (592) the corresponding customer record.The roll routine is then called (594) to roll/update the customer recordas described in connection with FIG. 9 c, and the status roll subroutineis called to roll status to the previous status (i.e., the customer'sstatus prior to becoming a NEGATIVE). The updated customer record (withits transfer date updated current) is then written (596) to the customerfile.

After the delete NEGATIVE function is accomplished, a confirmationresponse is written (597) to the specified response data address, and astop request is sent (598) to the System Kernal (which sets thespecified semaphore flag).

The routines that Adding/Delete CASH ONLY operate analogously to theAdd/Delete NEGATIVE routine because CASH ONLY is also maintained bylocation in a negative status record. These routines function inaccordance with FIGS. 9 d and 9 e, except that transaction data (BADFrequency/$Amount) is not involved (i.e., step 558 is unnecessary).

The routines that Add/Delete STOLEN affect only the customer file. Thus,these routines read the specified request data (check ID/status), andeither retrieve or, for the add routine, create a corresponding customerrecord. The customer record is updated using the roll routine, and thenrolled to STOLEN (add function) or to CAUTION (delete function) usingthe status roll subroutine. The updated customer record is written tothe customer file, and a confirmation response is written to thespecified response data location. The routine terminates with a stoprequest sent to the System Kernal.

The routines that Add/Delete PREAPPROVED and MANAGER ONLY operate toset/clear the corresponding user flags in the customer record in amanner analagous to the Add/Delete STOLEN routine. That is, theseroutines roll/update corresponding customer record, set/clear thespecified user flag, and then provide an appropriate confirmationresponse.

For the global update function, the host Data Manager Task receivesnegative status and selected customer records from all the remotesystems, and executes a host global update function. Host negativestatus and selected customer records are then sent to the remote DataManager Task which executes a remote global update function. The globalupdate function is implemented by the remote Event Manager Task whichexecutes a global update event/activity (see Section 3.5).

The criteria for selecting records for transfer in connection withglobal update are:

-   -   (a) Negative Status File—All records accessed since the previous        host/remote file transfer for global update (NEGATIVE or CASH        ONLY status); and    -   (b) Customer File—All customer records accessed since the        previous host/remote file transfer for global update, and having        a status value of CAUTION, NEGATIVE, CASH ONLY or STOLEN.        Since a remote location only accesses (updates) the negative        status records for its location, each remote only transfers to        the host negative status records for its location. The host        global update function necessarily accesses each negative status        record transferred by a remote during a global update session,        so that all such records are transferred back to each remote        (along with the host location negative status records that were        accessed as a result of local host operation.

FIG. 9 f is a program flow diagram for the host global update functionfor the negative status file. After receiving and decoding theappropriate intertask request packet (containing the global updaterequest from the remote Event Manager TAsk), the host Data Manager Taskdispatches (508) to the Host Global Update (Negative Status) executionroutine 600.

For each negative status record received (602) from a remote location,the host searches (604) its negative status file for a correspondingnegative status record for that remote location. If it does not exist,the remote record is copied (607).

If a corresponding host record is retrieved (606), the host NEGATIVEstatus (Active or Inactive) is replaced (608) with the remote NEGATIVEstatus from the remote negative status record, and the host BADFrequency/$Amount is replaced (610) with the remote BADFrequency/$Amount. The Access Date/Time is then rolled (612) current.

The updated (or copied) host negative status record for the remotelocation is written (614) to the negative status file, and the negativestatus file is searched (616) to determine if it contains any NEGATIVEstatus Active records for that customer for any locations (including theremote negative status record just processed).

If not (i.e., if NEGATIVE status for that customer is Inactive at alllocations), the corresponding customer record is retrieved (618) fromthe customer file. The record is updated by the roll routine (620), androlled to previous status (622). The updated customer record (with itstransfer date updated current) is then written (624) back to thecustomer file.

The Global Update (Negative Status) routine terminates with stop requestsent (626) back to the requesting remote Event Manager Task (see Section3.5).

FIG. 9 g is a program flow diagram for the host global update functionfor the customer file. After receiving and decoding the appropriateintertask request packet (containing the global update request from theremote Event Manager Task), the host Data Manager Task dispatches (508)to the Host Global Update (Customer) execution routine 630.

For each customer record received from the remote (632), the hostsearches (634) its customer file. If a corresponding customer recorddoes not exist, one is created (636) with the local DWTFrequency/$Amount set to zero.

If a corresponding host customer record is retrieved (635), it isupdated (638) in accordance with the roll routine in FIG. 9 c. If statusis CAUTION, POSITIVE or STOLEN, the status for the updated host customerrecord is compared (640) with the status for the remote customer record.If status is different, the host assigns (642) status in accordance withpredetermined arbitration rules, and updates its customer recordaccordingly. (If either host or remote status is NEGATIVE, global updateis accomplished through the Global Update routine for negative statusrecords.)

The host updates DWT Frequency/$Amount in the host customer record byadding (644) to the host DWT Frequency and $Amount the TransferFrequency and $Amount totals from the remote customer record, and thenselecting (646, 648, 649) the greater of the host or remote DWTFrequency/$Amount totals.

Finally, the host customer file is updated by writing (650) the hostcustomer record (with its transfer date updated current) to disk, and astop request is sent (652) to the remote Event Manager Task.

Once the host has completed updating its negative status file (FIG. 9 f)and its customer file (FIG. 9 g) for each negative status and customerrecord transferred by the remote, the remote then requests that the hosttransfer to the remote the host negative status and selected customerrecords that have been accessed since the previous transfer. That is,the same criteria that the remote used in selecting records for transferare used to select host records for transfer back to the remote.

Since for each remote record transferred to the host, the host performsan update operation that changes Access Date/Time, the host-to-remotefile transfer will necessarily result in all such updated records beingretransmitted back to the remote. In addition, the host will transfer tothe remote NEGATIVE status and selected customer records accessed andupdated by the host during either (a) local-host verification or updateoperations, or (b) a host global update operation initiated by anotherremote.

The remote receives the negative status and customer records transferredfrom the host, and performs a global update of its customer database. Asdescribed in Section 3.5, the remote Event Manager Task requests hostrecords from the host Data Manager Tasks, and then sends them to theremote Data Manager Task with a global update request.

The remote global update function for the negative status file is basedon two criteria: (a) for remote-location negative status records, theremote record is assumed to be correct and the remote record is ignored;and (b) for other-location negative status records, the host record isassumed to be correct and it is copied without any update or otheraccess by the remote. After receiving and decoding the appropriateintertask request packet (containing the global update request for thehost negative status record from the remote Event Manager Task), theremote Data Manager Task dispatches to the Remote Global Update(Negative Status) execution routine that implements these global updateoperations.

FIG. 9H is a program flow diagram for the remote global update functionfor the customer file. After receiving and decoding the appropriateintertask request packet (containing the global update request from theremote Event Manager Task), the remote Data Manager TAsk dispatches(508) to the Remote Global Update (customer) execution routine (660).

For each customer record received (662), the remote determines (664)whether it has a corresponding customer record, and if not, creates(666) one with the local DWT Frequency and $Amount data set to zero. Anexisting remote customer record is retrieved (665), and DWTFrequency/$Amount rolled (668) current. The remote then compares (670)its global DWT Frequency/$Amount with the corresponding totals from thehost customer record, and if the remote totals are greater, rolls (672)the Access Date/Time current. Updating the Access Date/Time for thecustomer record insures that that record will be transferred back to thehost during the next remote/host file transfer session. If the hosttransactional data is greater, then the Access Date/Time is not changed.

If status is CAUTION, POSITIVE or STOLEN, the status for the updatedremote customer record is compared (674) to the host customer recordstatus, and if different, the remote assigns (675) status in accordancewith predetermined arbitration rules. (If either host or remote statusis NEGATIVE, global update is accomplished through the host globalupdate function for negative status records.)

The updated customer record (with its transfer date updated current) iswritten (676) to the customer file, and a stop request is sent (678) tothe host System Kernal.

The arbitration rules used by the host during global update to assignstatus (642 in FIGS. 9G and 675 in FIG. 9H) for customer records in thecase of a conflict between host and remote status are a matter of designchoice and routine program implementation. The recommended criteria forspecifying arbitration rules are (a) where either the host or the remoteindicates POSITIVE and the other indicates CAUTION, the POSITIVE statusvalue is selected; (b) where either the host or the remote indicatesSTOLEN, the STOLEN status is selected; and (c) NEGATIVE status is notarbitrated.

The database operations associated with purge and backup are alsohandled by the Data Manager Task. These functions are implemented asevent activities by the Event Manager Task. In response to requests fromthe corresponding event activity routine, the Data Manager Taskretrieves the specified records and processes them in accordance withconventional record delete (purge) or copy (backup) operations. Thus,for backup, the Event Manager Task provides a backup key [status/accessdate/time], and all records accessed since the last backup are copied toa backup file. For purge, a purge routine operates analogously to theroll routine (FIG. 9 c) in reading purge limits from the system controlfile and comparing them against a purge interval defined by the lastaccess date/time, deleting (or copying off-line) those records that meetthe predetermined purge criteria.

3.4. Terminal Manager Task. The Terminal Manager Task manages thecommunication of requests/responses between the transaction terminalsand the transaction processor, implementing a token ring local areanetwork. In implementing token ring data communications, the TerminalManager Task sequentially polls each transaction terminal using thetoken ring protocol described in Section 1.2.

When request data (such as check ID/$Amount) are entered into atransaction terminal, the transaction terminal responds to its next POLLtoken by transmitting TXDATA answer packet including the request to theTerminal Manager Task, which writes the request data into thecorresponding terminal buffer.

For each request received from a transaction terminal, the TerminalManager Task spawns a terminal request subtask that:

-   -   (a) Builds a System Kernal service request for the request        entered into the transaction terminal;    -   (b) Sends the service request to the responding task through the        System Kernal;    -   (c) Receives response data from the responding task;    -   (d) Builds the appropriate response from the response data; and    -   (e) Sends the response to the transaction terminal.        The responding task depends upon the request function code        entered into the termina. (See Section 2.2) Most of the request        functions are for the Data Manager Tasks because they involve        customer database access. However, requests to the other tasks        for diagnostic or system information can be made from a        transaction terminal.

At system initialization, the Terminal Manager Task: (a) Initializes the32-port network communications interface (116 in FIG. 1A); (b) AllocatesTXBUFFER, RXBUFFER and LASTDATA terminal buffers for each of 32allowable terminals; and (c) Allocates two poll state flags, Poll/Dataand Wait, for each of 32 allowable terminals. The TXBUFFER buffer holdsTXDATA transmitted by the terminal, while the RXBUFFER buffer holdsRXDATA to be sent to the terminal. The LASTDATA buffer contains selecteddata from the last request transmitted by or the last response receivedby the terminal (used to hold data that might be used in the nextterminal request).

For the preferred embodiment, no attempt is made to deallocate terminalbuffers/flags for those communications ports that do not have an active,on-line transaction terminal. This design choice does not require anysignificant memory allocation for the 32-terminal configuration of thepreferred embodiment. Such deallocation procedures are a matter ofroutine program implementation.

FIG. 10A is a program flow diagram of the token ring networkcommunication function implemented by the Terminal Manager Task.

The Terminal Manager Task continually monitors (702) its task queue,which is maintained by the System Kernal. Through the System Kernal,system and diagnostic requests can be written into the queue forexecution by the Terminal Manager Task. That is, in response to a TMTrequest (such as a system diagnostic or system information request)written into its queue, the Terminal Manager Task calls (703) acorresponding routine that executes the request.

If no TMT request has been written into the task queue, the TerminalManager Task begins a token polling sequence (704, 706).

A token polling sequence is accomplished by sequencing through theterminal addresses 0-31. During each polling sequence the TerminalManager Task polls all 32 ports without regard to whether a port has anactive, on-line transaction terminal coupled to it, provided however,that an active terminal in a Wait state (i.e., waiting to receiverequested data) is not polled.

The Event Manager Task makes no attempt to segregate active and inactivecommunications ports, or to remove from the polling sequence terminaladdresses not assigned to active, on-line transaction terminals. Thisdesign choice does not significantly impact network communications forthe 32 terminal configuration of the preferred embodiment. Anactive-terminal-only pulling scheme would be a matter of routine programimplementation.

Terminal addresses are determined as follows.

During each polling sequence, the Terminal Manager Task polls each ofthe 32 ports—beginning with Port 0, a POLL token (including thecorresponding terminal address between 0 and 31) is broadcast and theTask waits until either (a) an answer packet is received, or (b) atime-out period transpires, before sending the next POLL. When atransaction terminal signs on, its internal network communicationsoftware causes an [ENTER TERMINAL ID] message to be displayed. Theterminal operator is supposed to enter a number between 0 and 31 that isuniquely assigned to that terminal; however, the internal softwareprocesses the terminal ID entry using module 31, so that any numericentry is forced into the 0-31 range.

For each terminal address the Terminal Manager Task determines (710) thepolling state of the corresponding transaction terminal—Poll, Wait, orData.

If the terminal is in the Poll state, the Terminal Manager Task sends(712) a POLL token for that transaction terminal (i.e., a token thatincludes the corresponding terminal address). The POLL is received bythe addressed terminal, and recognized as an invitation to transmitdata. The polled terminal transmits either a TXDATA answer (includingrequest data) or a NODATA answer. If a NODATA answer is returned (714),the Terminal Manager Task continues with the polling sequence. If thepolled terminal transmitted request data in TXDATA answer (715), theTerminal Manager Task writes (716) the request data into thecorresponding terminal buffer, sets (718) the terminal Wait state flag,and spawns (720) a terminal request subtask to execute the request, andthen continues the polling sequence.

During execution of the request, while the requesting terminal is in the“Wait” state, the Terminal Manager Task does not poll that terminal, butrather, continues with the polling sequence.

Once a request has been executed and the response data placed in theterminal buffer for the requesting transaction terminal, the requestsubtask sets the terminal Data state flag. During the next pollsequence, the Terminal Manager Task reads (722) the response from theterminal buffer and sends (724) an RXDATA token that includes theresponse.

When the token poll sequence is completed (i.e., terminal address 31),the task queue is checked (702) to determine whether any system ordiagnostic TMT requests have been written into the queue. If not, a newpolling sequence is commenced (704).

When the operator enters the terminal ID, the network software watchesfor that terminal address—when a POLL with that address is received, thenetwork software waits for a time-out to determine whether anotherterminal has that address. If not, the network software grabs the nextPOLL with that address and commences normal network communications.

For the preferred embodiment, the POLL token is one byte (0-7): Bit 7Token Flag (set if POLL token; otherwise clear) Bits 5-6 TX-POLL tokenRX-RXDATA token Bits 0-4 Terminal address

All data communications over the network are in 7 bit ASCII (0-6), sothat only the POLL token uses bit 7. The answer packets are also onebyte: Bit 7 Not used Bits 0-6 TXDATA NODATAThe TXDATA byte is followed by up to 40 characters of data in 7-bitASCII (0-6), with a single END of data byte (ASCII carriage return).Finally, the RXDATA token [Token Flag Set/RX/Terminal Address] isfollowed by up to 40 characters of data, with the next POLL tokendesignating END of data.

Thus, in operation, a transaction terminal watches the network for itsPOLL token (with its terminal address). When its POLL is received itsends back either a NODATA answer byte, or a TXDATA byte followed by upto 40 characters of data terminated in an END character. If the terminalis waiting for response data, so that it has been placed in a Waitstate, it will not receive a POLL token. When response data isavailable, the Terminal Manager Task will retrieve the data from theterminals'RXBUFFER and transmit it with the next TXDATA token.

This implementation for a token ring network is a matter of designchoice. Other implementations are a matter of routine program design.Commercial token ring program packages are available.

To execute a request sent by a transaction terminal during a pollingsequence, the terminal request subtask first determines which functionis requested, and then dispatches to an appropriate service requestroutine that:

-   -   (a) Builds a service request;    -   (b) Sends the service request to the responding task (via the        System Kernal);    -   (c) Builds an appropriate response from the response data        returned by the responding task; and    -   (d) Writes the response into the appropriate terminal buffer.        In addition, for a verify request, the verify service request        routine determines whether any “CALL MANAGER” limits have been        exceeded, and if so, causes the “CALL MANAGER” response to be        returned to the terminal.

From Section 3.2, a service request is in the following format:

-   -   Requesting task ID    -   Responding task ID    -   Function code    -   Address of request data location    -   Address for response data location    -   Semaphore flag        The service request is sent to the System Kernal, which builds a        corresponding intertask request packet.

The responding task that executes the request depends upon the functioncode. Of course, most function codes will be executed by the DataManager Task because they involve accessing in some way the customerdatabase.

After execution of the request, the response data returned by theresponding task depends upon the request function code. The Data ManagerTask returns updated customer or negative status records in response toverify/query requests and confirmations in response to local statusupdate functions and global update functions.

Exemplary terminal request subtask operation is described in connectionwith a verify request in which the responding task is the Data ManagerTask.

FIG. 10B is a program flow diagram for a terminal request subtask thatimplements a verification or query status request, to which the responsefrom the Data Manager Task is an updated customer record. The subtaskfirst reads (732) the TXBUFFER terminal buffer for the transactionterminal, parses (734) the request data to identify the function code(verify) and the other request data (check ID and $Amount).

The subtask then dispatches (736) the request to a verify servicerequest routine specified by the verify function code.

The service request subroutine builds (740) an appropriate servicerequest addressed to the Data Manager Task responding task), which issent (742) to the System Kernal.

The terminal request subtask then suspends execution and monitors (744)the semaphore flag specified in the service request. The semaphore flagis set by the System Kernal in response to a stop request from the DataManager Task, indicating that the request has been executed and responsedata (a customer record) written to the response data location specifiedin the service request.

The terminal request subtask then reads (746) the response data, andbuilds an appropriate response for the requesting terminal. For theverify (and query status) requests, the corresponding service requestroutine builds a response from the customer record (response data) onlyafter testing (750) corresponding user flags and CALL MANAGER limits.These user flag and CALL MANAGER operations are not required for otherfunction service requests (such as query negative, local status updateor global update).

The first operation in building an appropriate verification responsefrom the customer record returned by the Data Manager Task is to testthe MANAGER ONLY flag (752). If that flag is set, the verify servicerequest routine builds (754) a MANAGER ONLY response regardless ofcustomer status, and without testing any CALL MANAGER limits.

If the MANAGER ONLY user flag is clear, the next operation is to testthe PREAPPROVED flag (756). If the flag is set, and customer status isPOSITIVE (758), a normal (i.e. PREAPPROVED) response is built (762)without regard to any CALL MANAGER limits. If customer status is otherthan POSITIVE, the PREAPPROVED flag is ignored and CALL MANAGER limitsare tested.

After testing the user flags, the next operation in building a responsefor a verify request is to test the CALL MANAGER limits (760) for thecustomers status and DWT data. The DWT Frequency/$Amount CALL MANAGERlimits appropriate for the customer's status are read from the systemcontrol file and compared with DWT Frequency and $Amount from thecustomer record. If any CALL MANAGER limit is exceeded, CALL MANAGERRESPONSE is built (764) regardless of status. If no limits are exceeded,the normal response for that status is built (762).

As described in Section 2.3 and 2.10, the CALL MANAGER limits are usedto place predetermined transactional limits (DWT Frequency/$Amount) on acheck transaction primarily for customers with CAUTION and POSITIVEstatus. These limits are set as a matter of store policy, and placed inthe system control file during system configuration.

For function requests other than verify and query status, the user flagand CALL MANAGER operations (750) are not included in the servicerequest routine, and a normal response is automatically built (762) fromthe response data read (746) from the specified response data location.

The response—MANAGER ONLY, PREAPPROVED, CALL MANAGER or [Normal]—iswritten (766) into the appropriate terminal buffer, and when theterminal's RXBUFFER buffer is full, the terminal Data state flag is set(768) to indicate that a response is in the terminal's RXBUFFER bufferand should be sent to the terminal in the next polling sequence. Theterminal request subtask then terminates (770).

The basic operation of the terminal request subtask for each requestfunction is as described in connection with FIG. 10B for the verifyrequest, except that the service request routines for request functionsother than verify do not implement the user flag or “CALL MANAGER”response functions (750).

3.5. Event Manager Task. The Event Manager Task manages backgroundactivities that are executed automatically without operatorintervention, maintaining an Event File that includes an Event Table, anActivity Table and associated indices. The Event Table includes eventrecords each specifying an event time, an event interval and associatedactivity pointers into the Activity Table. The Activity Table includes alist of activity codes.

The basic activities implemented by the Event Manager Task are:

-   -   (a) Host/Remote Communications—These activities transfer        customer records and negative status records between host and        remote systems for global update;    -   (b) Purge—These activities, one for each status, delete customer        records and negative status records that are obsolete based on        specified purge limits contained in the system control file; and    -   (c) Backup—These activities are regularly invoked to backup the        customer and negative status files.        The host/remote communications and backup activities operate        only on those customer records or negative status records that        are accessed (i.e., that have their transfer dates updated)        after the last corresponding activity was performed. Host/remote        communications are implemented in connection with the Modem        Manager Task.

The Event Table contains an event record for each event, with each eventrecord including: (a) an event interval specifying the interval betweenexecution of the associated event activities; (b) the next event time,calculated by the event subtask after completing execution of anevent/activity based on the event interval and the system clock; (c) upto 10 activity pointers into the Activity Table; (d) active/inactiveflag set or cleared by a start/stop function request (F950 and 951 inTable 4); and (e) diagnostic abort flag that is tested duringevent/activity execution by the event subtask, and can be used to abortan event/activity.

In its basic operation, the Event Manager Task sequences through theevents (event records) in the Event Table, spawning a correspondingevent subtask to execute the specified activity.

Event/activities are started and stopped using a transaction terminal toenter a corresponding request (see the function codes 950 and 951described in Section 2.2 and set forth in Table 4). After entry of astart/stop request at a transaction terminal, the Terminal Manager Task(terminal request subtask) addresses a service request to the EventManager Task through the System Kernal. The Event Manager Task receivesthe service request from its task queue, executes the request bycorrespondingly modifying the event file, and returns an appropriateresponse to the Terminal Manager Task.

While event frequency for a given activity is a matter of store policyand design choice, typically, host/remote communications and backup willbe performed fairly frequently to insure both the regular update of thecustomer database, and the ability to recover from a system failurewithout significant loss of data. On the other hand, the purge functionis more a matter of system administration designed to control the sizeof the customer database. Indeed, the purge function can be omitted asan event activity. In that case, the status purge limits contained inthe system control file define the reset/CAUTION interval used in theroll routine to roll all statuses back to CAUTION if the specifiedreset/CAUTION (i.e., purge) limits are exceeded, as described inconnection with FIG. 9 b.

The selection and timing of event-driven activities is a matter ofdesign choice. The recommended event-driven activities, and theassociated event intervals, are: Host/Remote File Transfer Every 15minutes System Backup Every 10 minutes Database Purge Every 24 hours

The Event Manager Task sequences through the event file, selecting thespecified event-driven activities on a read-next basis. Event times arespecified as time intervals starting from a baseline system time00:00:00:00:00:00 [yymmddhhmmss] for Jan. 1, 1970 (the transactionprocessor includes a battery assisted hardware clock synchronized tothis baseline system time).

When an event time is reached, and the associated activity is completed,the event time is incremented by the event interval, based on theprevious event time and not on when the activity was actually completed.For example, if host/remote file transfers to support global updateactivities (i.e., transfers of negative status records and selectedcustomer records are to be accomplished every 15 minutes, then eachactivity is entered into the event file with an interval of 15:00[mmss]. The activity will be entered into the event file, along with itsevent interval and its initial event time of 15 minutes after systeminitialization (assumed to be 00:00 [mmss]). The activity will thenfirst be executed at 15:00, and when the activity is completed, theassociated event time will be incremented to 30:00.

At initialization, the Event Manager Task opens the Event Table andActivity Table, and clears all semaphore flags. Thereafter, the EventManager Task sequences through the Event Table, spawning event subtasksat specified event times to execute corresponding activities. While agiven event may have several activities associated with it, only oneevent subtask (and only activity within an event record) is executed ata time.

FIG. 11A is a program flow diagram for the Event Manager Task. The taskcontinually monitors (802) the Event Manager Task queue, to determine ifany EMT requests have been received from the System Kernal. Theserequests may be for diagnostic or system information purposes. If so,the appropriate system routine is executed (804).

If the task queue is empty, the Event Manager Task tests theevent-active semaphore (810) to determine whether an event is active. Ifso (semaphore set), the task checks the task queue (802).

If no event is active (semaphore clear), the Event Manager Task reads(812) the next event record from the Event File, and compares (814) theevent time in the event record with the current system time. If theevent is greater than or equal to the system time, the Event ManagerTask spawns (816) an event subtask to execute the activities associatedwith the event (sending a subtask request to the System Kernal).

The Event Manager Task then the task reads (812) the next event/activityfrom the event file.

If the event time for the next event/activity is greater than or equalto the current time (814), the Event Manager Task spawns (816) an EventSubtask to execute the event/activity.

FIG. 11B is a program flow diagram for the event subtask. At theappropriate event time, the Event Manager Task spawns the event subtask,which receives (822) the current event record from the Event Table. Thecurrent event record includes a current event time and an activitypointer to each of up to 10 associated activities identified in theActivity Table. The event subtask sequentially executes each activityassociated with the current event time.

Event subtask operation will be described in connection with executingat a remote system the activities associated with the global updatefunction. Specifically, the event subtask will be described inconnection with sequentially executing the following global updateactivities:

-   -   (a) Originate call;    -   (b) Send customer records (all selected statuses);    -   (c) Send negative status records (NEGATIVE and CASH ONLY);    -   (d) Receive customer records (all selected statuses); and    -   (e) Receive negative status records (NEGATIVE and CASH ONLY).        That is, each of the send/receive activities reads all selected        statuses. When the remote event subtask receives the event        record containing the event time pointers into the Activity        Table, it sets (824) the event-active semaphore (810 in FIG. 11        a), preventing the Event Manager Task from spawning another        event subtask. The subtask then initiates an activity sequence        (826, 828). Using the activity pointer in the Event Table, the        subtask sequentially reads (826) activity codes from the        Activity Table. The activity codes are read on a read-next        basis, with each read operation being tested to determine when        the last activity in the sequence is completed (828).

For each activity code read from the Activity Table, the event subtaskdispatches (830) to a corresponding activity routine for execution.

Each activity routine includes an activity data control data blockcontaining certain fixed and/or variable data used by the routine inexecuting the activity. Thus, for the global update event, the originatecall routine includes in its activity control data block the phonenumber for the host (as well as other system numbers that may be calledby the remote) and a corresponding log-in ID. The send/receive recordroutines include in their respective activity control data blocks theprevious event time for the activity which defined the end of theprevious event interval for that activity.

Thus, the current event interval for a global update (send/receive)activity is defined by the previous event time in the activity routine'scontrol data block, and the current event record. After execution of theactivity, the current event time is written into the activity routine'scontrol data block to define the beginning of the next global updateevent interval. (A similar control data block operation is used for thebackup activity.)

A global update event begins at a remote system with an originate callactivity that directs the remote Modem Manager Task (MMT) to establish acommunications link to the host. This activity is dispatched to anoriginate call routine (840) for execution.

The originate call routine begins by building and sending to the remoteMMT a request (842) to dial the host—the MT request includes a dialfunction code and the request data location into which the originatecall routine writes the host telephone number, together with a specifiedsemaphore flag. The originate call routine waits on a response from theMMT (843), periodically testing the stop semaphore flag. When thespecified semaphore flag is set by the MMT, indicating that the host hasbeen dialed and is in an off-hook condition opening a communicationsline, the originate call routine builds and sends to the remote MMT arequest (844) to send a log-in ID to the host MMT, writing the log-in IDinto a specified request data location. The originate call routine thenwaits on the specified stop semaphore flag being set (845). When thespecified semaphore flag is set, indicating that the remote MMT hascompleted log-in to the host system and established an activecommunications link, the originate call routine terminates by setting(846) a modem flag to indicate that a communications link is active, andthen returns (826) to the event subtask for execution of the nextactivity.

The event subtask reads (826) the code for the next activity in theglobal update activity sequence—the send customer record activity.

The event subtask dispatches (830) to the corresponding send customerrecord routine (850). The routine first reads (852) the previous endingevent time from its control data block to provide an initial customerrecord retrieval key to be used by the remote Data Manager Task (DMT) toretrieve a customer record from the customer record file. The retrievalkey includes two fields [check ID/transfer date/time]—each is used bythe Data Manager Task to sequence through the customer record file(incrementing check ID first and then transfer date/time).

The send customer record routine builds and sends to the DMT a request(854) to retrieve by the retrieval key the first customer record meetingthe criteria for transfer to the host during the current activity—anycustomer record that was accessed (updated) during the current eventinterval at any time after the time specified in the retrieval key(initially, the ending time for the immediately preceding event intervalduring which customer records were transferred to the host). The routinewrites the initial retrieval key (with check ID set to zero) into thespecified request data location to provide the DMT with the initialcustomer record retrieval key for the current event interval. The sendcustomer record routine then waits (855) on the specified stop semaphoreflag being set by the DMT.

The DMT receives the initial customer record retrieval request, anddispatches it to a corresponding customer record retrieval routine. Thisroutine reads the initial record retrieval key (including the endingtime for the previous event interval which is the beginning time for thecurrent event interval) from the specified request data location, andusing this initial key and the index [status/transfer date/check ID],retrieves the first customer record with an access date/time equal to orgreater than the beginning event time (if more than one customer recordhas the same access date/time, then the customer record with the lowestcheck ID is retrieved). When the DMT retrieval routine has retrievedthis first customer record in the current event interval, it provides anappropriate response to the send customer record routine, writing theretrieved customer record into the specified response data location andsending a stop request to the System Kernal.

When the stop semaphore is set (855), the send customer record routinereads the retrieved customer record from the specified response datalocation, and determines (858) that the DMT has returned a customerrecord. The routine then extracts (859) the transfer date/time and checkID from the retrieved customer record, and determines (860) that thecurrent event time, which defines the end of the current global updateevent interval, is greater than the transfer date/time for the retrievedcustomer record, thereby confirming that the retrieved customer recordwas accessed during the current event interval.

The send customer record routine then sends a global update servicerequest to the host DMT, along with the just-retrieved remote customerrecord, through the remote MMT (862). The routine then waits (863) onthe specified stop request being sent, along with a response(acknowledgement), by the host DMT through the host MMT and the remoteMMT to, respectively, the remote System Kernal and the specifiedresponse data location in the data area for the remote event subtask.

The above remote/host intertask communication operation is described ingreater detail in Section 3.6 (Modem Manager Task). Essentially, theModem Manager Task is designed so that remote/host intertaskcommunications is essentially transparent to the requesting andresponding tasks. That is, the remote/host requesting task sends aservice request with request data and a stop semaphore to its SystemKernal addressed to the host/remote responding task. The remote/hostMMTs provide an essentially transparent communications link between theremote/host System Kernals to effect the return of the stop semaphoreand response data from the host/remote responding task to theremote/host requesting task.

When the send customer record routine detects (863) the specified stopsemaphore flag being set, it requests (854) the DMT to retrieve the nextcustomer record in the current global update event interval, writing thetransfer date/time and check ID extracted (859) from the just-sentcustomer record into a request data location to provide a new retrievalkey for the DMT.

As with the first customer record retrieved in the current eventinterval, the DMT dispatches this request to a customer record retrievalroutine that reads the new retrieval key from the specified request datalocation, and using the index [status/transfer date/check ID], searchesthe customer file by incrementing first check ID and then transferdate/time until the next record is retrieved. The DMT retrieval routinethen responds to the customer record retrieval request, writing theretrieved customer record into the specified response data location forthe send customer record routine.

This procedure—requesting a customer record using the transfer date/timeand check ID for the previous record as the retrieval key, retrievingthat customer record by reading the customer file using the retrievalkey, sending the retrieved customer record to the host, and requestingthe next customer record—continues until either (a) the remote DMTresponds to a retrieve customer record request from the send customerrecord routine by indicating that the customer file contains no othercustomer records accessed after the just-sent customer record (asdetected in step 858), or (b) the send customer record routinedetermines that the customer record retrieved by the DMT has a transferdate/time after the current event time (which defines the end of thecurrent global update event interval as determined in steps 859, 860).In either case, the send customer routine returns to the event subtask(826), which reads the next activity from the activity table.

After the activity for sending customer records (by selected status) hasexecuted, the next activity specified in the Event Table is for sendingnegative status records (both NEGATIVE and CASH ONLY status). Thecorresponding routine in the event subtask for executing the sendnegative status record activity operates identically to the sendcustomer record routine (850) in retrieving negative status recordsaccessed during the current global update event interval from thenegative status file and sending those records to the host.

After negative status records have been sent, the receive customerrecords and negative status records activities are executed. Because ofthe essential transparency of the remote/host communications operationusing the host/remote MMTS, the receive activity is analogous to thesend activity. The remote receive record activity routine requestsrecords from the host DMT. The host DMT responds with globally updatedrecords that are sent by the remote routine to the remote DMT for remoteglobal update.

When the last send/receive activity for the global update function atthe current event time has been completed (i.e., the last receivenegative status record routine has completed transferring negativestatus records from the host DMT to the remote DMT for global update),that routine returns to the event subtask, which determines that thecurrent event time contains no more activities to be executed (826) sothat the activity sequence is complete (828). The event subtask thenchecks the modem flag (870) to determine whether any communications linkis active. In the present description of an exemplary operation of theevent subtask to execute a global update function, the originate callroutine (840) connects to the host and sets the event subtask modem flag(846).

Accordingly, at the completion of the activity sequence for the globalupdate function, the event subtask detects that the modem flag is set(870) and requests the MMT (872) to disconnect from the host. The eventsubtask monitors its semaphore flag (873) until notified by the remoteMMT that the communications link to the host has been terminated. Whenthe semaphore flag is set, the event subtask clears (874) the modemflag, and then clears (876) the event active semaphore in the EventManager Task. Finally, the event subtask (a) calculates the new eventtime for the event record based on the event interval and writes it intothe event record, and (b) writes the current event time into its controldata block for access during the next event/activity execution.

If the event subtask had been executing an event time and associatedactivity sequence in which communications was not necessary, such asbackup or purge, the event subtask detects that the modem flag is clear(870). In that case, the event subtask would immediately clear the eventactive semaphore (876) and terminate (878).

3.6 Modem Manager Task. The Modem Manager Task manages modemcommunications, primarily to support host/remote file transfer forglobal update, but also for remote diagnostic purposes. Operation forhost/remote file transfer depends in part upon whether the modem managertask is running in the host or remote check transaction processingsystem—all host/remote file transfers are initiated and controlled bythe remote system.

Modem communications through the Modem Manager Task are essentiallytransparent to the other tasks, functionally operating as an extensionof the normal intertask communications using intertask service requests.Thus, the remote Event Manager Task sends service requests to the hostData Manager Task through: the remote System Kernal, the remote ModemManager Task, the host Modem Management Task and finally the host SystemKernal. Similarly, the host Data Manager Task responds with a reply,including response data and a stop request, over the same host/remotecommunications path.

For remote-to-host file transfers, the remote Event Manager Task firstissues a dial host request to the remote Modem Manager Task, which theModem Manager Task executes by dialing the host Modem Manager Task anddetecting an off-hook condition at the host. When the remote EventManager Task is notified by a stop semaphore that a connection has beenmade, it requests the MMT to send a Log-In ID to establish an activecommunications link. The remote Event Manager Task then issues a servicerequest to the host Data Manager Task, which is directed by the remoteSystem Kernal into the Modem Manager Task queue. The Modem Manager Taskreads the request and sends it to the host system, where the host ModemManager Task transfers the request to the host Data Manager Task throughthe host System Kernal. The host data manager task responds with a replythat includes a stop request—this response is communicated through thehost/remote Modem Manager Task link to the remote Event Manager Task.

At system initialization, the Modem Manager Task opens itscommunications port, and conducts modem start-up diagnostic tests.

FIG. 12 is a program flow diagram for the Modem Manager Task. The taskcontinually monitor (902) its task queue to detect either (a) intertaskrequest packets written into the queue by the System Kernal, or (b) aring indication. When an intertask request packet is written into theModem Manager Task queue, the Task reads (904) the packet, and decodesthe function code and dispatches (906) the request to an appropriatemodem control routine: Dial, Send, Disconnect and Reset. Acommunications session will always be initiated with a Connect requestdirected to the Modem Manager Task, which executes the request bydialing the number specified by the request data (typically the host),and in conjunction with the host Modem Manager Task, establishing a lineconnection between the two systems.

Typically, when the remote Event Manager Task is advised (with a stopsemaphore) by the Modem Manager Task that the host answered the call anda line connection is made, the Event Manager Task sends, via the ModemManager Task a Log-In ID that establishes an active communications linkbetween the two systems. Once an active communications link isestablished, the remote/host file transfer procedure for communicatingnegative status and customer records is as follows.

The remote Event Manager Task sends a request for global update of arecord to the host Data Manager Task, writing the record into aspecified request data location. The remote System Kernal builds anintertask request packet and routes it to the remote Modem Manager Task.The Modem Manager Task reads (920) the request data from the locationspecified in the intertask request packet, and builds (922) acorresponding communications packet, including both the request and therequest data. The communications packet is sent (924) to the host ModemManager Task, and the remote Modem Manager Task waits for a reply.

When the Modem Manager Task receives (926) a reply from the host, whichincludes both response data (such as an acknowledgement) and a stoprequest, the response data is written (920) to the specified locationfor response data, and the stop request is sent (929) to the SystemKernal, which sets the appropriate semaphore flag.

This communication procedure is continued so long as requests are sentto the Modem Manager Task (920). A remote/host file transfer session isterminated by the remote Event Manager Task sending to the remote ModemManager Task a disconnect request (916).

The host and remote Modem Manager Tasks cooperate to establish acommunications link as follows. A communications session is initiated bya dial request from the remote Event Manager Task is directed to theremote Modem Manager Task, which responds by dialing the host.

A ring indication at the host modem is detected (908) by the host ModemManager Task, which directs the modem into an off-hook condition (930),establishing a remote/host connection.

The remote Event Manager Task then sends an appropriate log-inidentification (932).

File transfer communications are commenced when the host Modem ManagerTask receives (934) a communications packet from the remote ModemManager Task. The host Modem Manager Task builds (936) a correspondingservice request that is sent (938) to the host System Kernal.

The service request is directed to the designated responding task, suchas the host Data Manager Task, which executes the request and providesboth response data and a stop request. The host Modem Manager Task reads(940) the stop request from its queue, and reads (942) the response datafrom the specified location.

The host Modem Manager Task then builds (944) an appropriate replypacket (including the response data and the “stop” request), and sends(946) the reply to the host Modem Manager Task. The next communicationto the host Modem Manager Task will either be a Disconnect instruction(948) or another communications packet.

The Modem Manager Task implements remote/host communications functionsin a manner that is essentially transparent to the other tasks and theSystem Kernal. That is, intertask communications between a remote taskand a host task are accomplished in a manner identical to intertaskcommunications between tasks running in the same check transactionprocessing system, except that both the remote and the host SystemKernal are involved in the intertask communication, as are the remoteand host Modem Manager Tasks. However, the communications functionprovided by the remote and host Modem Manager Tasks is essentiallytransparent to the other tasks running in either the remote or the host.For example, the remote event subtask sends requests in the form ofservice requests to the host Data Manager Task just as it would sendrequests to the remote Data Manager Task. Specifically, the remote eventsubtask builds a request to the host DMT, and sends the service requestto the remote System Kernal. The remote System Kernal builds a innertask request packet and places it in the remote MMT task queue. Theremote MMT task reads the intertask request packet and builds acommunications packet for the request to the host DMT (includingfunction code, request data and stop semaphore flag). The remote MMTtransmits the communications packet to the host MMT, which builds acorresponding service request for the host System Kernal. The hostSystem Kernal builds an intertask request packet that is placed in thehost DMT task queue. The host DMT retrieves the intertask requestpacket, which constitutes a request from the remote event subtask, andexecutes it in the same manner that it would a request from the hostevent subtask, writing response data into the specified response datalocation and sending a stop request to the host System Kernal. The hostSystem Kernal, recognizing the stop request as being directed to theremote event subtask, builds an intertask packet with both the responsedata and the stop request and writes into the remote MMT task queue.

The remote MMT reads the intertask request packet, builds acommunications packet and sends it to the remote MMT. The remote MMTwrites the response data into a specified location in the data area forthe Event Manager Task, and sends the stop request to the remote SystemKernal. The remote System Kernal sets the specified stop semaphore,notifying the remote event subtask that response data from the host DMTis available, completing the request/response cycle.

4.4. ALTERNATIVE EMBODIMENTS

While the check transaction processing system has been described inconnection with a preferred embodiment, other embodiments within thespirit and scope of the invention as defined by the following claimswill be apparent to those skilled in the art.

For example, in the case of multiple-store systems, the preferredembodiment includes separate, essentially autonomous check transactionprocessing systems at each store site, thereby permitting each store toestablish and maintain an essentially local customer database, andlimiting off-site data communications activities to remote/host filetransfers for global update. However, the local customer database (andassociated disk system) need not be located at the store site, but maybe remote from the stores' transaction terminal network (such as bylocating it in a central office) so long as: (a) transaction terminalresponse time is not adversely affected and, (b) the essentially localcharacter of the customer database for each is maintained.

The preferred embodiment's implementation of a multitasking system usinga System Kernal for task-switching and intertask communications, can bereadily adapted to operate under a commercial, multi-tasking operatingsystem. These operating systems provide the task switching and intertaskmessage communications functions performed by the System Kernal.Adapting the CTPS multi-tasking program to a commercially availablemulti-tasking operating system is well within the programmingcapabilities of those skilled in the art. Each program task would bemodified in a conventional manner to accommodate the specific messagecommunication function implemented by the multi-tasking operatingsystem. TABLE 1 CUSTOMER RECORD SPECIFICATION Field Name Descriptionchar id customer's bank id char status current status (CAUTION,NEGATIVE, POSITIVE, CASH ONLY, STOLEN) char flags id user flags[PREAPPROVE, MANAGER ONLY] long curr date last access date long lastdate last transfer date long statdate date status changed int hitcntlocal total hit count char hitfreq local hit count frequency, previous 7days long amtfreq local amount frequency, previous 7 days long amountlocal last dollar amount verified long totamt local total dollar amountverified long date local access time int hitcnt global total hit countchar hitfreq global total hit count frequency, previous 7 days longamtfreq global amount frequency, previous 7 days long amount global lastdollar amount verified long totamt global total dollar amount verifiedlong date global access time char status previous status before currentint lhitcnt previous local hit count long ltotamt previous local dollaramount int ghitcnt previous global hit count long gtotamt previousglobal dollar amount long statdate previous status date int hitcnt totalhits since last transfer long totamt total dollars since last transfer

TABLE 2 NEGATIVE STATUS RECORD SPECIFICATION Field Name Description charid customer's bank id char COlocid location showing CASH ONLY charNlocid location showing negative char Nstatus current record statusNEGATIVE CHAR COstatus current record status CASH ONLY long currdatecurrent access date long COstatdate date became CASH ONLY long Nstatdatedate became negative int hitcnt total bad checks against location longtotamt total bad dollars against location

TABLE 3 SYSTEM CONTROL FILE SPECIFICATION Field Definition int hitcnthit count limit long amount dollar amount limit VfyLimit char locidsystem id int port keypad comm port int pollcnt keypad poll counterlimit int recvcnt kaypad poll receive limit keypad int port modem commport value char tone tone/pulse dial mode modem long strttime systemstart time (machine turned on) long currtime current system time charerrfile error filename char loggile screen log filename char passwordsystem access password char flags system control flags sysinfo chardayflag flag for day/second roll limits long ctnroll caution to positivelimit long ctnlim caution purge limit long neglim negative purge limitlong poslim positive purge limit long colim cashonly purge limit longsclim stolen purge limit database VfyLimit dmax day maximum call managerlimits VfyLimit wmax week maximum call manager limits VfyLimit tmintotal minimum call manager limits callmgr[5]

TABLE 4 FUNCTION CODE SPECIFICATION Function: F1 Description: Query ID,displaying current data Keypad Input: [id] F1 Keypad Output: StatusDhitcnt Whitcnt Thitcnt $totamt StatDate ID Function: F2 Description:List Negative Locations for entered ID Keypad Input: [id] F2 KeypadOutput: NEG LOCATIONS LOC1 LOC2 LOC3 . . . LOC10 Function: F3Description: Query Negative location ID as found on F2 Keypad Input:[id] F3 $n *n - LOCn as shown on F2 display Keypad Output: Neg InquiryLOCn Thitcnt $totamt negdate Function: F4 Description: Query Location IDKeypad Input: [id] F4 Keypad Output: LOC locid locname Function: F5Description: Query ID Hitcounts and Dollar Amounts Keypad Input: [id] F5Keypad Output: Status Dhitcnt; amount Whitcnt; amount Thitcnt; amountFunction: F40 Description: Add Cashonly ID Keypad Input: id F40 KeypadOutput: CASH ONLY FILE id Function: F41 Description: Add Stolen IDKeypad Input: id F41 Keypad Output: STOLEN FILE id Function: F42Description: Add Preapproved ID Keypad Input: id F42 Keypad Output:PREAPPROVED Function: F43 Description: Add Manager Only Keypad Input: idF43 Keypad Output: MANAGER ONLY id Function: F44 Description: AddNegative ID with location Keypad Input: id F44 Keypad Output: NEGATIVEFILE id Function: F55 Description: Verify ID. If F55 is not included,verify is assumed Keypad Input: id [F55] Keypad Output: *if any limitsare exceeded: CALL MANAGER id *status is caution: CAUTION hitcnt id*status is negative: NEGATIVE id *status is positive: POS DhitcntWhitcnt Thitcnt id *status is cashonly: CASH ONLY id *status is stolen:STOLEN id Function: F60 Description: Delete Cashonly ID Keypad Input: idF160 Keypad Output: CHECKS ACCEPTED id Function: F61 Description: DeleteStolen ID Keypad Input: id F61 Keypad Output: CHECKS ACCEPTED idFunction: F66 Description: Add Positive ID. Remove stolen list KeypadInput: id F66 Keypad Output: PAID OFF FILE id Function: F77 Description:Login to system to gain access to privileged commands Keypad Input: idF77 Keypad Output: Login Valid Begin Session Function: F62 Description:Delete Preapproved Keypad Input: id F62 Keypad Output: PREAPPROVEDFunction: F43 Description: Delete Manager Only Keypad Input: id F63Keypad Output: MANAGER ONLY Function: F88 Description: Logout fromsystem Keypad Input: F88 Keypad Output: End Session Bye! Function: F900Description: Return System Author Information Keypad Input: F900 KeypadOutput: CVS v4.20 (c) 1989 CVC, by Scott Wood, CCP Function: F901Description: Return System Internal Date & Time Keypad Input: F901Keypad Output: System Date mm/dd/yy-hh:mm:ss Function: F902 Description:Return System Memory Usage Keypad Input: F902 Keypad Output: SystemMemory b Bytes Free Function: F903 Description: Return Disk Usage KeypadInput: n F903 *n-3 = Drive C *n-4 = Drive D Keypad Output: Disk Usage(CID) Bytes: n Total, n Free Function: F904 Description: Return IDDatabase Size Keypad Input: F904 Keypad Output: ID Database n RecordsFunction: F905 Description: Return Negative ID Database Size KeypadInput: F905 Keypad Output: Negative dBase n Records Function: F906Description: Return System Information depending on n Keypad Input: nF906 Keypad Output: *n-0 - System ID Location ID locid *n = 1 - KeypadData Keypad Info Port: n, Poll: n, Recv: n *n = 2 - Modem Data ModemInfo Port 0: n, Port 1: n *n = 3 - System Start Time Start Timemm/dd/yy-hh:mm:ss *n = 4 - System Current Time Current Timemm/dd/yy-hh:mm:ss *n = 5 - System Password Password passid *n = 6 -System Flags Flags n *n = 7 - Caution Roll Period Caution Roll n seconds*n = 8 - Caution Purge Limit Caution Limit n seconds *n = 9 - NegativePurge Limit Negative Limit n seconds *n = 10 - Positive Purge LimitPositive Limit n seconds *n = 11 - CashOnly Purge Limit CashOnly Limit nseconds *n-12 - Stolen Purge Limit Stolen Limit *n = 13 - Caution CallManager Limits Caution Callmgr Dhitcnt, amount - Whitcnt, amount -Thitcnt, amount *n = 14 - Negative Call Manager Limits Negative CallmgrDhitcnt, amount - Whitcnt, amount - Thitcnt, amount *n = 15 - PositiveCall Manager Limits Positive Callmgr Dhitcnt, amount - Whitcnt, amount -Thitcnt, amount - *n = 16 - Cashonly Call Manager Limits CashonlyCallmgr Dhitcnt, amount - Whitcnt, amount - Thitcnt, amount - *n = 17 -Stolen Call Manager Limits Stolen Callmgr Dhitcnt, amount - Whitcnt,amount - Thitcnt, amount - Function: F940 Description: Toggle ScreenLogging Keypad Input: n F940 *n = 0: Off, 1: On Keypad Output: ScreenLog (ON|OFF) Function: F950 Description: Start Event Activity for eventn Keypad Input: n F950 [mmddmmss] *n = event number Keypad Output: Eventn Stopped Function: F951 Description: Stop Event Activity for event nKeypad Input: n F951 Keypad Output: Event n Stopped Function: F952Description: Get Event Activity for event n Keypad Input: n F952 *n =event number Keypad Output: mm/dd/yy-hh:mm:ss act1 act2 act3 . . . act10Function: F953 Description: Get Activity Status for activity n KeypadInput: n F953 *n = event number Keypad Output: activity descriptionactivity data Function: F960 Description: Toggle Keypad Debug ModeKeypad Input: n F960 *n = 0: Off, 1: On Keypad Output: Keypad Debut(ON|OFF) Function: F961 Description: Return Keypad number associatedwith current pad Keypad Input: F961 Keypad Output: Keypad Number nFunction: F970 Description: ₋ ₋ ₋ Keypad Input: F970 Keypad Output:Modem Debug (ON|OFF) Function: F971 Description: Reset Modem KeypadInput: F971 Keypad Output: Reset Modem Function: F980 Description:Toggle Data Manager Debug Mode Keypad Input: n F980 *n = 0: Off, 1: OnKeypad Output: DataBase Debug Function: F981 Description: Open databasesystem if currently closed Keypad Input: F981 Keypad Output: Open dBaseFunction: F982 Description: Close database system if currently openKeypad Input: F982 Keypad Output: Close dBase Function: F983Description: Return Internal Database Status Keypad Input: F983 KeypadOutput: Database Status B: bsyflag, H: hltflag, C: clsflag, Dbg:Dbgflag, E: error, D: doserr Function: F990 Description: Toggle SystemSupervisor Debug Mode Keypad Input: n F990 *n = 0: Off, 1: On KeypadOutput: SysServe Debut (ON|OFF) Function: F999 Description: Shut SystemDown Keypad Input: password F999 Keypad Output: System Halted

1-7. (canceled)
 8. A computer implemented system for providing a signalat a point-of-sale depending upon a customer's shopping history,comprising: a terminal for entering, during a transaction, a uniquecustomer identification; a database storing transaction data from priortransactions for a plurality of customers, such that data regarding acustomer's prior transactions are stored in association with anidentification of that customer; circuitry responsive to the entry ofsaid unique customer identification at said terminal during saidtransaction for transmitting to said point-of-sale during saidtransaction a customer information response signal; and wherein saidcustomer information response signal depends upon data stored in saiddatabase indicating dollar amount of at least one prior purchaseassociated with said unique customer identification.
 9. The system ofclaim 8 wherein said customer information response signal depends upondollar amount of a plurality of prior purchases associated with saidunique customer identification.
 10. The system of claim 8 wherein saidcustomer information response signal also depends upon a frequency ofprior purchases associated with said unique customer identification. 11.The system of claim 8 wherein said terminal can also receive customertransaction data.
 12. The system of claim 8 wherein said data regardingsaid individual customer's prior transactions stored in association withsaid individual customer's identification in said database includestransaction frequency and dollar amount.
 13. A computer implementedmethod for providing a signal at a point-of-sale depending upon acustomer's shopping history, comprising the steps of: entering in aterminal, during a transaction, a unique customer identification;storing, in a database, transaction data from prior shoppingtransactions for a plurality of customers, such that data regarding acustomer's prior transactions are stored in association with said anidentification of that customer; transmitting to a point-of-sale duringsaid transaction a customer information response signal in response tothe entry of said unique customer identification at said terminal duringsaid transaction; and wherein said customer information response signaldepends upon data stored in said database indicating dollar amount of atleast one prior purchase associated with said unique customeridentification.
 14. The method of claim 13 wherein said customerinformation response signal depends upon dollar amount of a plurality ofprior purchases associated with said unique customer identification. 15.The method of claim 13 wherein said customer information response signalalso depends upon a frequency of prior purchases associated with saidunique customer identification.
 16. The method of claim 13 furthercomprising the step of receiving in said terminal customer transactiondata.
 17. The method of claim 13 wherein said data regarding saidindividual customer's prior transactions stored in association with saidindividual customer's identification in said database includestransaction frequency and dollar amount.
 18. A computer implementedsystem for updating data in a customer database, comprising: a terminalfor entering, during a transaction, a unique customer identification andtransaction data for said transaction; a database storing transactiondata for a plurality of customers from prior shopping transactions, suchthat transaction data regarding prior transactions of a customer arestored in association with identification of that customer; andcircuitry responsive to the entry of said unique customer identificationand said transaction data at said terminal for updating transaction dataand a dollar amount of purchases associated with said unique customeridentification in said customer database, and for storing in saidcustomer database the date that transaction data association with saidunique customer identification was updated.
 19. The system of claim 18wherein said circuitry updates said transaction data associated withsaid unique customer identification during said transaction.
 20. Thesystem of claim 18 wherein said database also stores a time of day thatsaid transaction data was updated in association with said uniquecustomer identification.
 21. A computer implemented method for updatingdata in a customer database, comprising the steps of: entering in aterminal, during a transaction, a unique customer identification andtransaction data for said transaction; storing, transaction data for aplurality of customers from prior shopping transactions, such that dataregarding a prior transactions of a customer are stored in associationwith identification of that customer; and updating transaction data anda dollar amount of purchases associated with said unique customeridentification in said customer database in response to entry of saidunique customer identification and said transaction data at saidterminal; and storing in said customer database the date thattransaction data association with said unique customer identificationwas updated.
 22. The method of claim 21 wherein said circuitry updatessaid transaction data associated with said unique customeridentification during said transaction.
 23. The method of claim 21further comprising the step of storing in said database a time of daythat said transaction data stored in association with said uniqueidentification was updated.
 24. A computer implemented customer databasecomprising stored transaction data from prior point-of-sale transactionsfor a plurality of customers, such that data regarding a customer'sprior transactions are stored in association with an identification ofthat customer said transaction data stored in association with anidentification of that customer including: dollar amount of purchasesand time period.
 25. A computer implemented customer database comprisingstored transaction data from prior transactions for a plurality ofcustomers, such that data regarding a customer's prior transactions arestored in association with an identification of that customer, saidtransaction data stored in association with said identification of thatcustomer including: total dollar amount of purchases purchased during aperiod of time.
 26. The database of claim 25 wherein said period of timeis one of a day and a week.
 27. The database of claim 25 wherein saidtransaction data stored in association with said identification of thatcustomer further comprises a number of transactions associated with anidentification of a customer.
 28. The database of claim 25 wherein saidtransaction data stored in association with said identification of thatcustomer further comprises a frequency of transactions.
 29. The databaseof claim 25 wherein said transaction data stored in association withsaid identification of that customer further comprises a frequency oftransactions for a specified period of time associated with anidentification of a customer.
 30. The database of claim 29 wherein saidspecified period of time is one of a day and a week.
 31. The system ofany one of claims 8, 13, 18, 21, 24, and 25, wherein said database islocal to the point-of-sale, said database stores transaction data fromprior transactions for a plurality of customers such that data regardinga customer's prior transactions are stored in association with anidentification of that customer, and said database is updatable from aglobal database concatenated from multiple store databases includingsaid transaction data from the prior transactions of the customers atmultiple stores.
 32. The system of claim 8 wherein said database storesthe date that transaction data association with said unique customeridentification was updated.
 33. The system of claim 8 wherein saidterminal is in a first retail store, said database is a first storedatabase, and said first store database is located at said first retailstore.
 34. The system of claim 33 further comprising: a second storedatabase local at a second retail store, said second store databasestoring transaction data from prior transactions at said second storefor a plurality of customers, such that data regarding a customer'sprior transactions are stored in said second store database inassociation with a unique identification of that customer; and a globaldatabase storing transaction data from prior transactions in both saidfirst retail store and said second retail store.
 35. The system of claim34 further comprising at least one data connection, said at least onedata connection enabling transmission of data stored in said first storedatabase and said second store database to said global database, andenabling transmission of data from said global database to each one ofsaid first store database and said second store database.
 36. The systemof claim 35 configured to update customer records in said first storedatabase based upon data stored in said global database.
 37. The systemof claim 35 configured to update customer records in said first storedatabase based upon data stored in said global database for transactionsthat occurred in said second retail store.
 38. The system of claim 37configured to update customer records in said first store database basedupon data transmitted to said global database from said second storedatabase for transactions that occurred in said second retail store. 39.The system of claim 37 configured to update customer records in saidsecond store database based upon data stored in said global database fortransactions that occurred in said first retail store.
 40. The databaseof claim 24, wherein said database is structured to store in associationwith said identification of that customer transaction data including afirst frequency of transactions by that customer during a first periodof time.
 41. The database of claim 40, wherein said database isstructured to store in association with said identification of thatcustomer transaction data including a second frequency of transactionsby that customer during a second period of time.
 42. The database ofclaim 41, wherein said database is structured to store in associationwith said identification of that customer transaction data including athird frequency of transactions by that customer during a third periodof time.
 43. The database of claim 24, wherein said database isstructured to store in association with said identification of thatcustomer transaction data including a first dollar amount for one ormore transactions by that customer during a first time period.
 44. Thedatabase of claim 43, wherein said database is structured to store inassociation with said identification of that customer transaction dataincluding a second dollar amount for one or more transactions by thatcustomer during a second time period.
 45. The database of claim 44,wherein said database is structured to store in association with saididentification of that customer transaction data including a thirddollar amount for one or more transactions by that customer during athird time period.
 46. The database of claim 24, wherein said databaseis structured to store in association with said identification of thatcustomer a customer status.
 47. The database of claim 46, wherein saiddatabase is structured to store in association with said identificationof that customer a date/time that said customer status changed.
 48. Thedatabase of claim 47, wherein said database is structured to store inassociation with said identification of that customer a previous statusof said customer.
 49. The database of claim 24, wherein said database isstructured to store in association with said identification of thatcustomer a user flag.
 50. The database of claim 24, wherein saiddatabase is structured to store in association with said identificationof that customer a transfer date/time indicating when the customer'srecord was last written to disk.
 51. The database of claim 24, whereinsaid database is structured to store in association with saididentification of that customer an access date/time indicating when thecustomer's record was last accessed and updated.
 52. The database ofclaim 24, wherein said database is structured to store in associationwith said identification of that customer a total number of transactionssince a last global update, said global update updating data stored inassociation with said identification of that customer based upon datastored in association with said identification of that customer in asecond database.
 53. The database of claim 52, wherein said database isstructured to store in association with said identification of thatcustomer a total dollar volume since said last global update.
 54. Thedatabase of claim 24, wherein said database is structured so that it isindexed at least by customer identification.
 55. The database of claim24, wherein said database is structured so that it is indexed at leastby status.
 56. The database of claim 24, wherein said database isstructured so that it is indexed at least by transfer date.
 57. Acomputer implemented system comprising: computer implemented customerdatabase comprising stored transaction data from prior point-of-saletransactions, said stored transaction data comprising: (1) data for afirst customer such that data regarding said first customer's priortransactions are stored in a first customer record associating a firstcustomer identification of said first customer with at least a firstcustomer first dollar amount; and (2) data for a second customer suchthat data regarding said second customer's prior transactions are storedin a second customer record associating a second customer identificationof said second customer with at least a second customer first dollaramount; a point of sale terminal; a digital data processor; and whereinsaid system is programmed to respond to transaction information receivedfrom the point of sale terminal including said first customeridentification by identifying said first customer record in saiddatabase, and returning to said point of sale terminal a first customerinformation response signal; wherein a value of said first customerinformation response signal depends at least in part upon data stored insaid first customer record, including at least said first customer firstdollar amount.
 58. The system of claim 57 wherein a value of said firstcustomer information response signal also depends at least in part upondata stored in said first customer record, including at least a firstcustomer second dollar amount.
 59. The system of claim 58 wherein avalue of said first customer information response signal also depends atleast in part upon data stored in said first customer record, includingat least a first customer third dollar amount.
 60. The system of claim57 wherein a value of said first customer information response signalalso depends at least in part upon data stored in said first customerrecord, including at least a first customer first frequency value. 61.The system of claim 60 wherein a value of said first customerinformation response signal also depends at least in part upon datastored in said first customer record, including at least a firstcustomer second frequency value.
 62. The system of claim 61 wherein avalue of said first customer information response signal also depends atleast in part upon data stored in said first customer record, includingat least a first customer third frequency value.
 63. The system of claim58 wherein a value of said first customer information response signalalso depends at least in part upon data stored in said first customerrecord, including at least a first customer first frequency value. 64.The system of claim 63 wherein said signal also depends at least in partupon data stored in said first customer record, including at least afirst customer second frequency value.
 65. The system of claim 57wherein said signal also depends at least in part upon data stored insaid first customer record, including at least a first customer firststatus value.
 66. The system of claim 65 wherein said signal alsodepends at least in part upon data stored in said first customer record,including at least a first customer first flag value.
 67. The system ofclaim 57 wherein said signal also depends at least in part upon datastored in said first customer record, including at least a firstcustomer first time value.